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ABSTRACT 


in  the  current  circumstances  of  the  Korean  Army,  the  engineer  units  perform  two 
major  missions  -  river  crossing  and  obstacle  denial  operations  -  to  support  the 
combined  arms  team.  To  accomplish  these  missions,  engineer  units  need  various  kinds 
of  data  and  information  during  the  planning  phase  of  operations.  This  kind  of  data 
and  information  can  be  provided  by  the  information  processing  system  that  is  to  be 
developed  in  this  thesis. 

This  thesis  is  to  apply  a  computer  based  information  processing  system  to  the 
planning  phase  of  the  military  operations.  The  author  presents  an  intelligent  decision 
support  system  for  the  Army  Engineer  Operations,  specifically  the  river  crossing  and 
obstacle  denial  operations.  The  purpose  of  this  system  is  to  maintain  and  analyze  the 
related  information  stored  in  the  computer  and  to  provide  the  resulting  information  to 
the  commanders  and  their  staffs  to  help  them  make  their  decisions  more  effectively. 
To  accomplish  this  task,  the  author  has  used  the  structured  system  analysis  and  design 
methodology  through  the  system  development  process,  and  has  implemented  the  river 
crossing  operation  in  a  microcomputer  with  dBASE  III  Plus  as  an  example.. 
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In  modern  society,  a  great  deal  c f  information  is  disseminated  in  our  daily  life 
through  the  news  media  such  as  newspaper,  magazine,  and  television  or  radio 
broadcasting.  We  need  information  for  various  purposes.  However,  it  is  hard  to  get 
the  desired  information,  particularly  at  the  time  when  we  need  it.  Moreover,  it  is 
impossible  to  remember  all  of  the  information  that  we  have  ever  received.  Fortunately, 
the  advance  of  the  computer  technology  has  facilitated  much  this  particular  problem. 
The  computer  can  store  and  retrieve  vast  amounts  of  information,  that  can  be  used  to 
an  advantage. 

Information  processing  is  a  major  activity  in  today's  society.  A  significant  part 
of  an  individual's  working  and  personal  time  is  spent  recording,  searching  for,  and 
absorbing  information.  Thus,  computers  have  become  an  essential  part  of  the 
individual  or  organizational  information  processing,  The  current  challenge  is  how  to 
gain  the  maximum  benefits  with  the  use  of  the  computers  in  different  activities, 
including  managerial  tasks  and  decision  making. 

The  ancient  Chinese  strategist  Sonja  said  in  war,  "IVe  can  win  100  times  in  100 
battles  if  nv  have  all  the  information  about  our  enemy  and  ourselves."  This  exemplifies 
the  importance  of  information  for  military  operations.  For  example,  during  World 
War  II,  the  combined  forces  made  the  turning  point  in  the  European  front  with  the 
Normandy  Landing  Operations.  At  that  time.  Hitler  and  his  staff  had  not  enough 
information  about  the  combined  allied  forces.  They  believed  that  the  allied  forces 
would  land  at  the  coast  of  Pas  De  Calais  in  France  because  Pas  De  Calais  is  the 
nearest  coastal  area  from  England  and  they  thought  that  the  combined  allied  forces 
have  net  enough  troops,  fleets  and  aircrafts.  But  the  combined  forces  had  enough 
troops,  fleets  and  aircrafts  for  the  landing  operations.  They  also  had  enough 
information  about  the  terrain  of  the  alternative  landing  area  and  the  enemy's  course  of 
action.  They  succeeded  because  they  conducted  the  ianding  operation  at  the 
Normandy  coast  while  Hitler  prepared  strong  defense  along  the  coast  of  Pas  De  Calais, 
and  a  weak  defense  along  the  coast  of  Normandy. 

In  the  modern  military  situations,  we  need  various  kinds  of  information  when  we 
prepare  an  operation.  Information  about  the  capability  of  the  enemy  and  the  friendly 
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forces,  about  the  terrain  and  weather  of  the  operation  area,  and  about  the  enemy's 
course  of  action  is  extremely  valuable.  Most  of  the  times,  commanders  have  to  do 
analysis  and  evaluation  of  the  information  quickly.  This  is  necessary  because  in  the 
modern  battle  fields,  both  the  friendly  and  the  enemy  forces  are  highly  modernized  and 
their  combat  powers  are  devastating  and  their  movements  are  rapid. 

The  basic  idea  of  this  thesis  is  to  apply  computer  based  information  processing 
system  to  the  army  engineer  operation  in  a  military  operation.  Two  major  engineer 
operations,  river  crossing  operation  and  obstacle  denial  operation,  are  analyzed  in 
detail.  During  the  engineer  operations,  a  commander  and  his  staff  have  to  analyze  a 
large  amount  of  information  related  to  the  operations  within  a  very  limited  amount  of 
time.  In  the  proposed  system  of  this  thesis,  information  and  data  will  be  stored  in  the 
computer  for  consistency,  accuracy  and  ease  of  access.  Furthermore,  to  nelp  the  users 
make  decisions  fast,  some  of  the  processes  in  which  decisions  are  derived  will  be  done 
by  the  computer  with  the  results  fed  back  to  its  users.  In  other  words,  the  goal  of  my 
thesis  is  to  develop  a  microcomputer-based  intelligence  decision  support  system  to 
increase  the  operational  capability  of  the  commanders  and  staffs. 

A  decision  support  system! DSS)  is  a  coherent  system  of  computer  based 
technology  used  by  managers  as  an  aid  to  their  decision  making  in  semi-structured 
decision  tasks.  Decision  support  systems  allow  the  decision  maker  to  retrieve  data  and 
test  alternative  solutions  during  the  process  of  problem  solving.  The  decision  support 
system  should  provide  ease  of  access  to  the  database  containing  relevant  data  and 
interactive  testing  of  solution.  Expert  systems  are  a  type  of  decision  support  system 
that  incorporate  the  knowledge  base  and  heuristics  of  an  expert  with  a  flexible  interface 
>o  that  even  a  novice  can  use  the  system  to  solve  problems.  The  primary  requirements 
cf  decision  support  for  intelligence  is  the  ability  to  search  the  database  for 
opportunities  and  problems.  In  order  to  design  a  DSS,  the  designer  must  understand 
the  process  of  decision  making  for  each  situation. 

Chapter  II  discusses  the  background  which  relates  to  the  military  operation. 
especi.iiA  the  army  engineer  operation  concepts  in  various  situations.  In  Chapter  III. 
'.  e  hr  -t  discuss  the  system  analysis  and  requirements.  Problem  definition,  description 
.-0,1'  exiting  system,  and  requirements  specification  are  done  in  this  chapter.  In 
uM.tiv'r.  e  v.  .l!  develop  the  high  level  data  (low  diagram  and  functional  decomposition 
:  t.u  Ic'l’.c.s!  model.  In  Chapter  IV.  we  discuss  the  system  design  process  and  the 
implementation  of  the  proposed  svstent.  Finally,  in  Chapter  V,  conclusions  and 
uui  inundations  are  presented. 


II.  BACKGROUND 


A.  ARMY  OPERATION  CONCEPTS 

1.  Introduction 

The  goal  of  all  operations  is  to  destroy  or  hold  ofT  the  opposing  force.  At  the 
foundation  of  the  Army's  operations  are  the  principles  of  war  and  their  application  to 
classical  and  modern  warfare.  An  army  unit  will  conduct  all  types  of  operations  to 
preserve  its  status  and  to  exploit  the  enemy's  weaknesses.  It  will  attempt  to  achieve  its 
goal  through  the  use  of  fire  power  or  by  out-maneuvering  its  enemy.  It  will  maintain 
the  agility  necessary  to  shift  forces  and  fires  to  be  directed  to  the  enemy's  weak  sides. 
To  achieve  its  goal,  an  army's  operations  must  be  rapid,  unpredictable,  devastating, 
and  disorienting  to  the  enemy.  The  pace  must  be  fast  enough  to  prevent  him  from 
taking  effective  counter  actions.  Operational  planning  must  be  precise  so  that  the 
combined  arms  operation  in  a  battle  is  well-coordinated.  It  must  also  be  sufficiently 
flexible  to  respond  to  changes  or  to  capitalize  on  fleeting  opportunities  to  exert 
maximum  damage  to  the  enemy. 

2.  Offensive  Operations 

The  military  operation  is  divided  into  two  large  groups:  offensive  operations 
and  defensive  operations.  Offensive  operations  are  characterized  by  aggressive 
initiatives  on  the  part  of  the  subordinate  commanders,  by  rapid  shifts  in  emphases  to 
take  advantage  of  opportunities,  and  by  the  use  of  the  destructive  power  to  bring 
destruction  to  the  enemy's  defenses  as  rapidly  and  as  extensively  as  possible. 

The  offensive  operations  are  undertaken  to  achieve  several  purposes.  As 
destroying  the  enemy's  fighting  force  is  the  only  sure  way  of  winning,  offensive 
operations  are  primarily  intended  to  destroy  the  enemy's  forces.  However,  it  is  not 
necessary  to  defeat  ever/  enemy  combat  formation  to  win.  Attacks  that  avoid  the 
enemy's  main  strength  but  shatter  the  will  of  the  opposing  army  or  to  reduce  its 
fighting  capability  are  the  fastest  and  the  cheapest  way  of  winning.  Offensive 
operations  also  have  secondary  purposes,  ail  of  which  contribute  to  destroying  the 
enemy.  Elements  of  large  attacking  forces  may  undertake  offensive  operations 
specifically  to  secure  key  or  decisive  terrain  because  it  has  a  serious  effect  to  a  combat 
situation,  and  as  we  know,  the  situation  of  resources  has  in  the  past  determined  the 
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outcomes  of  many  wars.  Therefore  to  deprive  the  enemy  of  resources  is  one  of  the 
purpose  of  offensive  operations.  In  addition  we  can  gain  information  about  the 
enemy's  current  situation  through  offensive  operations.  And  we  can  deceive  and  divert 
the  enemy  s  attentions  to  irrelevant  or  unimportant  matters.  Also  we  can  hold  the 
enemy  in  position  during  the  preparation  of  an  offensive  operation  to  allow  us  to 
attack  the  enemy  from  other  directions.  All  of  these,  plus  others,  serve  as  objectives  of 
offensive  operations.  [Ref.  1:  p.  S — t] 

3.  Defensive  Operations 

Whether  an  offensive  operation  is  a  success  or  a  failure,  we  have  to  prepare 
defensive  operations  afterward  because  they  are  important  to  retain  the  gain  of  the 
offensive  operations  and  to  prepare  the  next  phase  of  an  offensive  operation.  Some 
military  theorists  think  defense  is  the  stronger  form  of  war  because  denying  the 
enemy's  success  goes  before  achieving  our  own  success.  Indeed,  the  defenders  have 
significant  advantages  over  the  attackers.  In  most  cases  they  not  only  know  the 
ground  better,  but  having  occupied  it  first,  have  strengthened  their  position.  Therefore 
we  conduct  defensive  operations  to  achieve  several  purposes.  Throughout  a  defensive 
operation,  a  defender  can  block  an  enemy's  attack  and  concentrate  forces  elsewhere  to 
attack  enemy's  weak  points  while  holding  up  the  enemy  forces  in  front  of  his  defense 
position.  Further  he  can  control  the  key  terrain  to  the  advantage  of  the  defensive  or 
offensive  operations  on  his  side  .  Besides,  it  also  take  more  offensive  power  to 
overcome  a  defense;  thus  his  defensive  operation  generally  can  tie  down  more  of  the 
enemy's  manpower.  [Ref.  I:  p.  10-3] 

-k  Sequence  of  Commander  and  Staff  Actions 

The  sequence  of  actions  in  making  and  executing  a  decision  involves  a  series 
of  separate  actions  or  steps.  As  shown  in  Figure  2.1.  a  higher  headquarters  normally 
assigns  the  mission  to  the  subordinate  units,  but  the  commander  of  a  unit  usually 
develops  or  expands  the  mission.  The  commander  may  initiate  his  mission  analysis  at 
this  point.  After  that  his  staff  provides  the  commander  the  available  relevant 
information.  Based  on  this  information,  the  commander  completes  his  mission  analysis 
and  issues  his  planning  guidance  to  his  staff.  The  purpose  of  the  mission  analysis  is  to 
insure  that  the  commander  fully  understands  his  mission  and  to  allow  him  to  develop 
those  tasks  that  are  essential  to  the  accomplishment  of  the  mission.  At  this  time,  the 
commander  normally  includes  in  his  initial  guidance  the  mission  restated  appropriately 
as  determined  by  his  mission  analysis  [Ref.  2-5:  p.  5-13]. 
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Based  on  the  restated  mission  and  planning  guidance  received,  the 
coordinating  stafT  officers  who  may  also  prepare  their  own  estimates  when  required, 
prepare  their  staff  estimates  with  the  assistance  of  the  special  officers.  In  turn,  the 
coordinating  staff  officers  present  their  final  estimates  to  the  commander, 
recommending  the  actions  that  the  commander  should  take  to  accomplish  the  mission. 
After  presenting  the  recommendation,  the  commander  considers  the  recommendations 


of  his  staff,  completes  his  own  estimate,  and  announces  his  final  decision.  Following 
the  decision  statement,  the  commander  may  provide  the  staff  his  overall  concept  of' 
how  the  operation  will  he  conducted,  which  is  generally  an  amplification  of  his  decision 
along  with  some  necessary  explanation. 

Based  on  a  complete  understanding  of  the  commander's  decision  and  the 
concept  of  the  operation,  the  staff  members  determine  the  actions,  including  the 
preparation  of  plans  or  orders  required  by  the  command  to  earn'  the  operation  to  a 
successful  completion.  Normally  the  staff  submits  plans  and  orders  to  the  commander 
for  approval  before  they  are  published  as  plans  or  orders.  After  publishing  and 
distributing  plans  or  orders  to  the  surbodinate  units,  the  command's  and  staffs 
supervision  of  the  execution  of  orders  is  a  continuous  action.  Therefore,  whenever  a 
commander  receives  the  mission  from  his  higher  headquarters,  a  plan  or  order  is 
generated  by  a  sequence  of  commander  and  staff  actions. 

B.  ENGINEER  SYSTEMS  IN  THE  ARMY 

Today  more  than  ever  before,  the  engineer  units  play  a  critical  role  as  a  member 
of  the  combined  arms  team  and  they  fight  as  an  integral  part  of  it.  As  movement  and 
intensity  on  the  battle  Held  increase,  the  requirement  to  reinforce  a  position 
complementing  the  natural  terrain  increases.  The  engineer  brings  to  the  combined 
arms  team  a  terrain-oriented  system  that  enhances  the  capability  of  our  weapon 
systems  while  decreasing  the  effectiveness  of  the  enemy's  weapons.  The  idea  is  to 
employ  the  engineer  unit  as  far  forward  as  possible  with  the  fighting  units. 

1.  Organization  of  Engineer  Systems 

In  the  Republic  of  Korea  Army(ROKA),  the  engineer  systems  arc  organized 
under  the  Division,  Corps  and  Field  Army  Commands.  But  each  level  of  command  has 
a  different  type  of  engineer  units  and  their  missions,  capabilities,  and  equipments  are  a 
little  bit  different  from  each  other.  An  engineer  unit  divides  into  division  engineer, 
corps  engineer,  and  field  army  engineer. 

a.  Division  Engineer 

Each  infantry  and  mechanized  infantry  division  has  an  original  engineer 
battalion.  A  division  engineer  batalion  consists  of  a  Headquarters  and  a  Headquarter 
CompanyfHHC).  three  combat  engineer  companies,  and  a  bridge  company  as  shown  in 
Figure  2.2.  The  IIIIC  is  organized  into  the  normal  staff  sections  and  an  equipment 
platoon.  Generally  each  combat  engineer  company  has  5  officers  and  144  enlisted  men 
organized  into  a  Company  I Icadquarters(HQ)  and  three  platoons.  The  bridge 
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company  has  5  officers  and  146  enlisted  men  organized  into  two  heavy  raft  sections, 
one  armored  launch  bridge(AVLB)  section  and  a  company  HQ.  The  heavy  raft 
sections  have  a  M4T6  float  bridge  which  is  a  river  crossing  equipment  to  move  across 
the  heavy  combat  equipments  such  as  tanks  and  armored  vehicles  by  bridging  or 
rafting.  The  mission  of  the  division  engineer  battalion  is  to  increase  the  combat 
effectiveness  of  the  division,  and  to  carry  out  an  infantry  mission  when  required  by  the 
division  commander  [Ref.  3:  p.  B-8], 


Engineer 

Ccxrpany 


i 
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Figure  2.2  Organization  of  Division  Engineer. 


The  mission  capability  of  a  division  engineer  battalion  is  to  emplace  and 
remove  obstacles  like  mines  and  boobytrap,  to  make  possible  either  carefully  or  hastily 
planned  river  crossings  with  boats,  rafts,  and  temporary  bridges,  and  to  construct, 
repair,  and  maintain  roads,  bridges,  landing  strips  and  helipads.  Further,  the  duties  of 
a  disision  engineer  battalion  is  to  assist  in  the  assault  of  fortified  positions,  to  install 
and  operate  portable  water  supply  facilities,  and  to  provide  reconnaissance  to  gather 
engineer  intelligence. 

b.  Corps  Engineer 

Engineer  brigades  are  organized  under  each  corps  command  that  consists  of 
three  or  more  divisions.  An  engineer  brigade  consists  of  three  to  five  engineer 
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battalions  and  a  heavy  equipment  company,  a  panel  bridge  company,  a  dump  truck 
company,  and  a  floating  bridge  company  as  shown  in  Figure  2.3. 
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Figure  2.3  Organization  of  Corps  Engineer. 

A  battalion  consists  of  HHC  and  four  line  companies.  The  HHC  consists 
of  the  normal  staff  and  company  sections  plus  an  equipment  platoon,  and  a  combat 
construction  sectionfplumbers,  carpenters,  and  other  skilled  construction  trades).  Each 
line  company  consists  of  5  officers  and  139  enlisted  men  organized  into  a  company  HQ 
and  three  platoons.  Each  battalion  has  the  same  organization  as  a  division  engineer 
battalion  but  the  mission  of  corps  engineer  battalions  that  are  organized  under  an 
engineer  brigade,  is  to  increase  the  combat  effectiveness  of  the  corps  by  means  of 
engineering  combat  support  and  general  engineering  work,  to  reinforce  the  divisional 
engineer  units  when  required,  and  to  perform  infantry'  combats  as  necessary,  fhe 
responsibilities  of  corps  engineer  battalion,  like  those  of  the  division  engineer,  is  to 
construct,  and  repair.  A  commander  of  corps  can  operate  any  engineer  battalion  or 
engineer  company  organized  under  an  engineer  brigade  or  corps  command  [Ref.  3:  p. 
B- 1 5). 
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c.  Field  Army  Engineer 

Each  Field  Army  Command  in  the  ROKA  has  two  to  four  corps 
commands,  and  they  also  have  engineer  units,  called  field  engineer  groups.  An 
engineer  group  is  similar  to  an  engineer  brigade  but  it's  a  little  bit  smaller. 

An  engineer  group  consists  of  three  to  four  engineer  battalions  and  a  light 
equipment  company,  a  panel  bridge  company,  a  dump  truck  company,  and  a  floating 
bridge  company.  Each  battalion  is  organized  into  an  HHC  and  three  engineer 
companies.  Each  engineer  company  consists  of  6  officers  and  186  enlisted  men 
organized  into  a  company  HQ,  a  horizontal  construction  platoon,  and  two  general 
construction  platoons.  [Ref.  3:  p.  B-16] 

The  mission  of  an  engineer  group  is  to  construct  and  rehabilitate  roads, 
airfields,  pipeline  system,  structures,  and  utilities  for  the  Army  and  Air  force,  to  assist 
in  emergency  recovery  operations,  to  increase  the  combat  effectiveness  of  the  division, 
corps,  and  army  group  forces  by  means  of  engineering  combat  support  and  general 
engineering  work,  and  to  perform  infantry  combat  mission,  when  required. 

The  capability  of  an  engineer  group  includes  the  construction  or 
rehabilitation  of  routes  of  communications,  bridges,  forward  tactical  and  forward  cargo 
airfields  and  heliports,  and  to  provide  limited  reconstruction  of  railroads,  railroad 
bridges,  and  ports  of  the  corps  rear  area. 

2.  Objectives  of  Engineer  Systems 

In  any  kind  of  army  operations,  an  army  must  contain  its  the  engineer  system 
the  skills  and  equipment  to  provide  mobility  and  survivability  to  friendly  forces, 
counter  mobility  to  the  enemy,  and  to  accomplish  general  engineering  work  to  friendly 
forces.  [Ref.  3'.  p.  2-2  -  2-6] 
a.  Mobility 

In  modern  battle  fields,  to  be  more  effective  than  our  enemy,  we  must 
move  into  and  out  of  battle  positions  faster  than  our  enemy.  Mobility  is  achieved 
through  reducing  or  negating  the  effects  of  existing  obstacles  to  facilitate  the 
movement  of  maneuver  fro  units  and  critical  supplies.  Thus,  the  engineers'  work 
include  breaching  the  obstacles  created  by  tire  enemy's  counter  actions  such  as 
minefields,  road  craters,  and  ditches,  by  using  their  organized  equipments  to  make 
quick  b;  pass  around  them  when  it's  not  possible  to  breach  the  obstacles,  and  bridging 
the  gaps  with  their  equipment  or  with  timber  that  can  be  obtained  around  the  battle 


b .  Counter  Mobility 

The  enemy  will  try  to  improve  the  advance  of  fire  power  and  maneuver 
units  to  destroy  the  friendly  forces  or  to  secure  a  key  terrain  for  the  next  operation. 
Therefore,  friendly  forces  have  to  reduce  the  enemy's  advance  effectively.  In  order  to 
limit  the  enemy's  movement,  we  do  various  kinds  of  counter  actions  like  emplacing 
obstacles  such  as  minefields,  road  craters,  abatis,  and  road  block  etc.,  as  dictated  by 
the  battle  field  with  whatever  available  resources.  Also  engineer  units  demolish  road 
structures  such  as  bridges,  tunnels  etc.  that  can  seriously  hamper  the  enemy's  advance. 

c.  Survivability 

Survivability  is  the  development  of  protective  positions.  Normally, 
positions  are  expedient  in  nature,  providing  only  side  and  frontal  protection  against 
direct  and  indirect  fire  weapon  systems.  The  greatest  number  of  protective  positions 
are  constructed  in  the  defensive  because  the  fire  power  of  modern  battle  fields  is  very 
destructive.  The  engineer  units  provide  the  specialized  equipment  and  expertise  to 
assist  maneuver  units  to  increase  their  survivability  in  battle  field. 

d.  General  Engineering 

General  engineering  is  the  support  of  units  and  activities  in  the  brigade  and 
division  rear  areas.  The  division  engineer  battalion  is  staffed  and  equipcd  to  work  for 
the  committed  maneuver  brigades.  Corps  engineers,  who  are  supporting  the  division, 
provide  the  primary  capability  to  accomplish  general  engineering  tasks  in  the  division 
area.  General  engineering  missions  are  improving  and  maintaining  essential  combat 
and  main  supply  routes,  replacing  assault  or  blown  bridges  with  tactical  bridging, 
clearing  minefields,  providing  potable  water,  and  providing  terrain  studies  etc. 
[Ref.  3:  p.  3-32] 

3.  Engineer  Operations 

As  already  mentioned  before,  the  engineer  system  provides  mobility,  counter 
mobility,  survivability,  and  general  engineering  as  a  member  of  the  combined  arms 
team  during  the  Army  operations  [Ref.  3:  p.  2-2].  To  accomplish  their  own  missions, 
engineer  operations  are  divided  into  three  large  groups  such  as  river  crossing 
operations,  obstacle  creation  and  denial  operations,  and  recovery  operations. 

a.  River  Crossing  Operations 

Rivers,  lakes,  and  canals  arc  critical  natural  obstacles  hindering  maneuvers 
during  offensive  and  defensive  operations.  We  plan  and  conduct  river  crossing 
operations  in  order  to  move  combat  power  across  these  obstacles.  1  he  objects  e  ol 


river  crossing  operations  is  to  project  combat  power  across  a  water  obstacle  while 
retaining  the  integrity  and  momentum  of  the  force. 

Engineer  units  conduct  river  crossing  operations  as  a  member  of  the 
combined  arms  team.  In  the  planning  phase  of  a  river  crossing  operation,  engineer 
units  have  to  provide  information  to  their  commander  about  available  crossing  sites 
and  their  characteristics  and  available  river  crossing  equipments  to  support  the 
combined  arms  team.  In  the  executing  phase  of  the  river  crossing  operation,  the 
engineer  units  use  river  crossing  equipments  to  build  floating  bridges  or  rafts,  and 
operate  these  equipments. 

A  river  crossing  is  a  special  operation  in  that  it  requires  substantial  amount 
of  planning  and  support.  Two  types  of  crossing  are  conducted,  the  hasty  and  the 
deliberate  crossing.  Which  type  of  crossing  is  to  be  selected  depends  on  the  mobility  of 
the  friendly  and  enemy  forces,  the  river  conditions,  and  the  required  crossing  speed. 
[Ref.  4:  n.  1-2] 

Hasty  river  crossings  are  hurriedly  planned,  decentralized  operations  using 
existing  or  expedient  means.  Such  is  the  case,  for  example,  when  a  crossing  is 
conducted  as  a  continuation  of  an  attack  with  little  or  no  loss  of  momentum  by  the 
attacking  force.  In  this  case  a  hasty  crossing  is  preferred  over  a  deliberate  crossing. 
Hasty  crossings  are  feasible  when  enemy  defenses  are  weak  or  can  be  overcome  by  our 
own  fires,  and  when  the  maneuver  forces  are  equipped  to  rapidly  advance,  cross,  and 
continue  the  attack. 

Deliberate  river  crossings  are  done  when  a  hasty  crossing  is  not  feasible, 
when  an  earlier  one  has  failed,  or  when  the  offensive  operations  commence  at  the  r;- 
line.  Plans  for  a  deliberate  crossing  generally  include  more  centralized  contrc 
crossing  means,  tire  support,  crossing  time  and  other  supporting  elements  than  the 
for  a  hasty  crossing.  A  deliberate  crossing  is  required  when  prevailing  conditions 
preclude  the  execution  of  a  hasty  crossing.  This  generally  means  that  the  enemy 
defenses  are  very  strong  or  that  the  river  obstacle  is  very  severe  and  cannot  be  crossed 
by  expedient  means. 

When  a  division  commander  has  received  a  warning  order  of  a  riser 
crossing  operation  from  the  higher  command  headquarters,  he  first  announces  to  his 
staff  about  their  own  mission.  After  that  the  commander  and  his  staff  will  work  to 
prepare  the  river  crossing  plan  by  a  sequence  of  commander  and  staff  actions  as 
mentioned  before.  In  order  to  prepare  a  river  cross.ng  operation  plan,  the  engineer 
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battalion  commander,  who  is  a  special  staff  of  the  division  commander  for  the  engineer 
system,  surveys  the  river  crossing  area  to  estimate  the  various  elements  of  the  river 
crossing  operation.  To  accomplish  his  mission,  he  cooperates  with  the  operation 
staff(G-3>  and  the  logistic  stafi{G-4)  to  get  some  kind  of  information  about  the  combat 
organization  of  the  division  for  this  operation  and  logistic  data  about  the  division. 

Based  on  the  information  obtained,  he  first  examine-,  to  see  if  bridges  exist 
in  the  division’s  operation  boundary7.  This  is  done  because  he  needs  to  estimate  the 
required  number  of  crossing  sites  based  on  the  information  about  the  combat 
organization,  and  logistic  data.  For  example,  usually  each  division  needs  6  raft  sites 
and  2  oridge  sites  of  class1  45  or  more.  However,  if  there  is  already  one  bridge  of  class 
45,  then  he  needs  only  1  more  bridge  site  and  6  raft  sites  to  accomplish  the  river 


crossing  operation. 

After  examining  the  existence  of  bridges  in  the  specified  area  and  estimating 
the  required  number  of  additional  crossing  sites,  he  selects  the  crossing  site  by  using 
any  available  information  about  the  river  at  each  crossing  site  such  as  width,  depth, 
velocity,  bottom  condition  etc.  If  he  has  no  information  about  the  river  at  the  crossing 
sites,  estimation  would  be  very-  difficult  because  it's  hard  to  get  this  kind  of  information 
in  the  battle  field.  Therefore  the  engineers  need  to  keep  this  kind  of  information  with 
them  through  the  terrain  studies  before  conducting  a  river  crossing  operation. 

Once  the  crossing  sites,  have  been  selected,  the  engineer  battalion 
commander  can  estimate  the  requirement  of  the  equipments.  However  if  there  is  not 
enough  equipment  to  support  a  division's  river  crossing  operation,  then  he 
recommends  to  the  higher  command  headquarters  to  get  support  from  other  engineer 
units.  Through  a  sequence  of  this  kind  of  action,  the  battalion  commander  and 
G-.v  operation  staff)  make  a  river  crossing  plan  and  finally  recommend  the  course  of 
action  to  the  division  commander.  River  crossing  operations  are  generally  very- 
difficult.  because  we  must  estimate  accuratly  and  rapidly  what  is  to  be  done  for  this 


kind  of  operation. 


b.  Obstacle  and  Denial  Operation 

The  primary  purpose  of  obstacle  use  is  to  enhance  the  effectiveness  of 
friendly  fires.  The  use  of  reinforcing  obstacles  coordinated  with  existing  obstacles 
makes  it  possible  for  a  commander  to  delay  and  disrupt  enemy  formations.  A 


;Class  is  a  gross  weight  of  wheeled  vehicles  or  tracked  vehicles  in  ton.  1  he 
bridge  class  number  which  will  permit  either  wheeled  or  trucked  vehicles  to  cross  if  the 
vehicle  class  number  is  equal  to  or  less  than  the  bridge  class  number. 


commander  can  also  use  obstacles  to  allow  him  to  distribute  his  forces  advantageously, 
strengthening  one  area  with  defensive  obstacles  so  that  it  can  be  lightly  defended  to 
free  the  forces  to  be  used  elsewhere.  He  can  also  use  obstacles  in  conjunction  with 
mobile  forces  to  protect  his  Hanks  and  other  lightly  defended  areas.  In  addition  to 
these  employment  of  obstacles,  the  destruction  of  a  transportation  network  also  delays 
the  enemy's  progress  [Ref.  5:  p.  3-4], 

In  the  modern  battle  field,  if  the  enemy  has  a  stronger  combat  power  than 
the  friendly  forces,  then  cur  defense  position  can  be  destroyed  and  we  may  have  to 
conduct  retrograde  operation  to  establish  new  defense  positions.  As  a  result,  a  enemy 
may  occupy  certain  area  once  occupied  by  friendly  forces.  During  a  retrograde 
operation,  we  try  to  gain  more  time  in  order  to  retreat  safely  and  to  prepare  new 
defense  positions.  Also  if  we  don’t  destroy  targets  such  as  bridges,  tunnels,  dams, 
airfields,  etc.,  then  our  enemy  can  use  these  facilities  to  advance  expeditiously.  And  if 
we  don't  destroy  facilities  of  the  key  industries,  then  our  enemy  can  use  these  facilities 
after  occupying  them.  Thus  we  make  denial  operation  plans  and  conduct  denial 
operations  to  destroy  certain  targets. 

But  the  object  of  a  retrograde  operation  is  to  occupy  a  new  defense 
position  and  to  conduct  counterattack  after  destroying  the  enemy  forces  at  the  new 
defense  position.  If  we  destroy  all  of  the  deny  targets  and  emplace  all  the  designated 
obstacles  during  a  retrograde  operation,  there  will  be  obstacles  for  our  counter  attack. 
It  will  then  require  enormous  efforts  and  resources  to  overcome  the  destroyed  targets 
and  breaching  the  installed  obstacles.  And  time  is  a  very  critical  factor  to  conduct 
denial  operations. 

In  ether  words  when  do  we  have  to  destroy  some  or  all  of  the  designated 
targets?  If  we  have  destroyed  a  certain  bridge  before  our  forces  have  crossed  this 
bridge,  or  i!"  we  fail  to  destroy  this  bridge  before  enemy  forces  arrives,  then  a  very 
critical  problem  for  the  next  operations  will  occur.  Therefore  a  commander  has  to 
make  a  very  careful  decision  which  target  and  at  what  time  do  we  have  to  destroy  a 
particular  target. 

Also  obstacle  and  denial  operation  plans  can  be  developed  under 
circumstances  of  offensive  operations.  When  we  try  to  attack  the  enemy,  we  need  to 
concentrate  major  combat  power  in  the  frontal  area  of  a  battle  field.  As  a  result  of  the 
concentration  of  combat  power,  the  franks  of  the  combat  boundary  might  be  weak 
against  the  enemy’s  counter  attack  during  an  offensive  operation.  For  this  reason,  we 


have  to  use  obstacles  to  reinforce  the  franks,  thus  reducing  the  threat  of  an  enemy's 
counter  attack.  Consequently,  we  have  to  develop  the  obstacle  and  denial  plan  not 
onlv  for  retrograde  and  defensive  operation  but  also  for  offensive  operations. 

Consider  the  case  that  a  commander  needs  certain  amount  of  time  to 
prepare  a  new  defense  position.  Then  he  first  gives  a  planning  guidance  to  his  staff'  for 
preparing  a  barrier  and  denial  operation  plan.  After  receiving  the  commander's 
planning  guidance,  his  staff  will  survey  the  designated  obstacles  and  denial  targets 
within  certain  segments  of  the  roads.  Based  on  these  information,  they  estimate  the 
delay  time  of  already  emplaced  obstacles  and  denial  targets.  But  if  the  estimated  delay 
time  is  not  enough  for  preparing  a  new  defense  position,  then  additional  targets  must 
be  selected  from  the  previously  planned  targets  and  obstacles  such  as  minefields,  road 
craters,  abatises,  and  bridges,  and  tunnels.  At  this  point,  his  staff  has  to  consider 
which  types  of  target  will  be  selected,  because  it's  a  very  important  factor  for  the 
following  operation  after  finishing  an  offensive  or  retrograde  operation.  Therefore,  a 
commander's  planning  guide  has  to  contain  criteria  for  choosing  additional  targets  and 
preparing  obstacle  and  denial  plans. 

However,  if  the  total  available  delay  time,  when  all  types  of  designated 
obstacles  arc  emplaced  and  all  types  of  targets  are  denied,  is  not  enough  for  the 
preparation  of  a  new  defense  position,  the  commander  will  have  to  change  his  planning 
guidance.  And  his  staff  can  proceed  to  complete  a  plan  in  accordance  to  the 
commander's  new  planning  guidance. 
c.  Recovery  Operation 

Maintaining  mobility  is  one  of  the  responsibilities  of  the  engineer  units  that 
are  members  of  the  combined  arms  team.  A  recovery  operation  is  to  recover  destroyed 
structures  or  facilities  by  friendly  or  enemy  forces.  As  mentioned  in  the  denial 
operations,  we  will  destroy  certain  facilities  to  deny  their  use  by  the  enemy  and  also  the 
enemy  will  destroy  their  facilities  to  deny  being  used  by  our  friendly  forces.  All  of 
these  destroyed  facilities  will  be  obstacles  to  the  movement  of  friendly  forces  when  we 
conduct  counter  attack  or  offensive  operations.  Therefore,  engineers  have  to  recover 
these  facilities. 

Recovery  can  be  divided  into  two  categories:  permanent  recovery  and 
temporary  recovery.  In  recovery  operations,  the  time  factor  is  the  most  important  one 
because  they  will  be  used  in  the  next  operation.  So  we  have  to  maintain  detail 
recovery  plans  and  enough  resources  and  equipments  to  complete  a  task  within  the 
required  time. 
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When  we  make  a  recovery  plan,  we  have  to  consider  how  to  recover  and 
u hat  material  will  be  used  for.  In  war  time,  we  usuallv  do  temporary  recoveries 
because  we  have  not  enough  time  to  perform  permanent  recovery  completely  and  also 
we  have  not  enough  material  for  that. 


III.  SYSTEM  ANALYSIS  AND  REQUIREMENTS 


A.  INTRODUCTION 

As  described  in  Chapter  II.  there  are  many  problems  in  order  to  plan  and 
conduct  any  kind  of  military  operations,  and  the  planning  process  of  an  operation  plan 
is  complicated.  In  this  chapter,  I  will  describe  what  are  the  problems,  what  is  the 
existing  system  being  used  in  the  ROKA  operation  planning  process,  what  are  the 
requirements  of  a  desired  system,  what  are  the  functional  aspects  of  a  computer  based 
operation  planning  support  system,  what  must  be  done  to  solve  the  problem  at  each 
level  of  an  operation,  and  what  is  the  logical  application  of  a  system. 

B.  PROBLEM  DEFINITION 

In  the  ROKA.  each  level  of  command  has  different  field  movement  exercises  such 
as  Team  Spirit,  which  is  the  world's  largest  annual  field  movement  exercise  conducted 
by  the  combined  forces  of  the  Republic  of  Korea  and  the  United  States  of  America, 
division  field  movement  exercise,  command  post  exercise(CPX),  which  is  an  exercise  for 
the  commander  and  stalls  in  the  field,  and  so  on. 

Each  command  has  to  make  an  operation  plan  for  an  exercise  every  time.  Stalls 
at  each  level  of  the  command  spend  a  lot  of  time  to  prepare  it  because  they  need 
information  about  the  area  where  they  conduct  the  exercise  and  the  area  changes  from 
exercise  to  exercise.  As  a  consequence,  various  problems  arise. 

•  Waste  of  time  and  effort  because  they  repeat  the  same  work  manually. 

•  Data  redundancy  and  inaccuracy  because  each  command  gets  data  and 
information  separately  about  the  same  objects.  As  a  result,  the  information  and 
data  are  a  little  bit  different  each  time  for  the  same  thing.  For  example, 
coordinates  of  certain  point,  width,  depth,  or  velocity  of  river  etc.  are  invariably 
different  when  specified  by  different  persons.  Also  it  is  difficult  to  get  data 
outside  a  unit's  own  boundary,  if  the  operation  is  conducted  outside  its  area. 

•  Lack  of  data  integration  and  security  problem  because  they  are  kept  in  the  file 
book.  Also  it  occupies  a  large  space. 

•  Difficulty  to  update  plan  or  data  in  the  file  book  because  they  have  to  rewrite 
the  different  part  of  the  operation  plan  and  distribute  it  to  the  higher 
commands,  adjacent  units,  and  surbodinatc  units. 


C.  DESCRIPTION  OF  EXISTING  SYSTEM 


All  military  units  need  to  get  various  kinds  of  data  and  information  in  order  to 
make  their  own  operation  plan  and  estimate  surrounding  situations  to  prepare  counter 
action  against  the  enemy.  As  mentioned  before,  in  current  circumstances  in  the 
Korean  Army,  the  engineer  units  perform  two  important  engineer  missions  -  river 
crossing  operation  and  obstacle  emplacement  operation  -  to  support  the  combined 
team.  To  accomplish  these  missions,  engineer  units  need  various  relevant  data  and 
information,  which  they  collect  through  terrain  studies  or  the  use  of  other  methods.  In 
addition,  engineer  units  always  keep  data  and  information  about  terrain,  roads,  rivers, 
deny  targets  such  as  bridges,  dams,  airfields  etc.,  and  obstacles  that  are  classified  or 
designated  as  targets. 

Once  the  engineers  of  a  unit  gets  information  about  certain  things  or  makes  a 
plan,  they  keep  one  or  more  copies  with  them  and  send  several  copies  to  their  higher 
level  commands.  Therefore  all  higher  level  commands  such  as  the  Army  Headquarters, 
the  Field  Army  command  and  the  Corps  Command  keep  a  lot  of  file  books  for  this 
kind  of  data  and  information.  If  a  certain  unit  gets  a  specific  mission,  the  working 
officers  participating  in  the  operation  have  to  search  first  the  file  books  to  get  the 
appropriate  information,  then  examine  the  relative  situations,  and  finally  make  a  plan 
accordingly. 

D.  REQUIREMENTS  SPECIFICATION 

The  analysis  phase  of  the  system  development  involves  project  planning  and 
system  requirement  definition.  Requirements  specify  the  capabilities  that  the  system 
must  provide.  These  include  functional  requirements,  performance  requirements,  and 
user  interfaces,  as  well  as  development  standards  and  quality  assurance  standards. 

Requirement  specification  based  on  the  System  Definition  is  a  technical 
specification  for  the  system.  The  goal  of  requirement  definition  is  to  completely  and 
consistently  specify  the  technical  requirements  for  the  desired  system  in  a  concise  and 
unambiguous  manner,  using  formal  notations  when  appropriate.  Requirement 
specification  states  the  "what"  of  the  software  product  without  implying  how'. 
System  design  is  on  the  other  hand  concerned  with  specifying  how  the  system  will 
provide  the  required  features  [Ref.  6:  p.  SSj. 

1.  Applied  Environment  of  Required  System 

As  described  in  the  Chapter  II.  the  engineer  system  conducts  various 
engineering  operations  to  support  the  army  operation  as  a  member  of  the  combined 


forces.  In  order  to  conduct  any  kind  of  operation,  each  unit  needs  an  operation  plan 
prepared  through  a  sequence  of  commander  and  stafF  actions.  Our  system  is  expected 
to  be  used  to  support  the  planning  process  for  these  actions. 

If  a  commander  receives  a  warning  order,  whether  a  river  crossing  or  an 
obstacle  denial  operation,  from  higher  headquarters,  the  commander  and  his  stall'  will 
try  to  get  relevant  information  to  make  a  suitable  plan.  At  this  point,  this  system  can 
be  used  to  support  their  decision  making  process  to  complete  a  plan  more  rapidly. 

2.  Description  of  Requirements 

We  can  divide  the  desired  computer  system  in  two  different  parts  according  tc 
the  two  major  operations,  river  crossing  and  obstacle  denial  operation,  because  these 
two  operational  functions  are  quite  different  from  each  other. 
a.  River  Crossing  Environment 

In  the  river  crossing  operation  environment,  the  computer  system  has  to 
perform  the  following  functions  to  support  the  planning; 

•  Estimate  Necessity.  If  certain  unit  tries  to  attack  the  enemy  across  a  ris  er,  the 
commander  and  his  staff  have  to  decide  whether  a  river  crossing  operation  is 
needed  or  not.  A  river  crossing  operation  may  not  be  needed,  if  there  are 
asadabie  bridges  in  the  operational  boundary.  Therefore,  our  system  has  to 
have  a  function  estimating  tire  necessity  of  river  crossing  operation  in  a 
situation. 

•  Estimate  Possibility:  If  a  river  crossing  operation  is  required,  the  commander 
and  his  staff  will  estimate  the  possibility  of  an  operation  based  cn  the 
availability  of  their  own  engineer  unit  and  equipment.  Therefore,  our  system 
must  do  this  kind  of  function. 

•  Select  Crossing  Sites:  The  system  is  required  to  perform  the  selection  of  the 
required  number  of  crossing  sites  and  to  provide  the  information  about  each 
crossing  sites  including  width,  depth,  velocity,  and  bottom  condition  of  the  river 
because  these  arc  needed  tc  make  a  river  crossing  pian. 

•  Calculate  Equipments  and  Assemble  Time:  After  selecting  the  crossing  sites,  the 
s\  s;crn  must  calculate  what  kind  of  and  how  many  equipments  are  needed  to 
carry  out  the  operation.  How  much  time  is  needed  to  assemble  these 
equipments  should  also  be  provided. 

•  Estimate  .'readable  Supporting  Unit:  If  available  equipments  are  not  enough  for 
a  specified  operation,  then  additional  equipment  must  be  sought.  Therefore, 
nir  system  has  to  have  a  function  to  search  which  units  have  equipments 
available  and  how  many  equipments  can  be  used  to  support  this  operation. 

•  Ea  taunt  ■  Crossing  Rate:  Finally,  a  system  must  generate  the  final  output  that 
contains  the  number  of  vehicles  or  equipments  that  can  cross  the  river  e\  cry 
hour  from  the  start  of  the  operation;  I  I-houn  and  an  estimate  of  the  time  when 
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all  vehicles  and  equipments  have  crossed  the  river  completely.  The  commander 
and  stall  can  made  a  decision  and  a  detailed  pian  based  on  this  final  outp  ut. 

b.  Obstacle  I  Denial  Environment 

In  obstacle  denial  operation  environment,  a  desired  system  lias  to  perform 
the  following  functions  to  support  planning: 

•  Estimate  Xecessily:  During  retrograde  operation,  a  commander  establishes 
obstacles  to  gain  certain  amount  of  time  in  order  to  withdraw  safely  and  to 
prepare  new  defense  positions.  1  or  examp!  ,f  the  commander  needs  5  hours 
for  this  purpose,  and  some  obstacles  are  already  emplaced,  then  he  has  to 
estimate  at  this  time  either  he  needs  more  obstacles  to  secure  5  hours,  or  he 
doesn  t  need  any  more  if  he  already  has  secured  more  than  5  hours  through  the 
already  emplaced  obstacles.  Our  system  must  h  ue  this  kind  of  function  to 
support  the  decision  making. 

•  Select  Targets:  In  case  the  already  secured  time  is  less  than  5  hours,  the 
commander  will  emplace  additional  obstacles  to  secure  the  needed  5  hours.  He 
must  survey  and  select  some  or  ail  the  designated  but  unemplaced  obstacles  and 
enable  them.  So  our  system  has  to  perform  this  function,  too. 

•  Extend  Segment:  If  all  obstacles  are  emplaced  in  a  certain  segment  of  a  road, 
and  the  available  delay  time  is  still  less  than  5  hours,  the  commander  has  to 
extend  the  segment  further  to  secure  5  hours.  Our  system  must  perform  this 
operation  as  well. 

•  Characteristics  of  Targets:  Frequently  we  need  to  know  the  characteristics  of 
certain  type  of  targets.  Our  system  must  provide  us  this  information  as  needed. 

E.  ANALYSIS 

The  objective  of  analysis  is  to  determine  what  must  be  done  to  solve  a  specific 
problem.  The  basic  function  of  any  data  processing  application  is  to  convert  the  input 
data  into  the  desired  output  information. 

In  this  section.  I  shall  attempt  to  develop  a  complete  functional  understanding  of 
the  proposed  system.  The  intent  is  not  to  determine  how  the  system  will  work,  but 
what  it  must  do  to  solve  the  problem.  As  mentioned  before,  this  thesis,  wc  shall 
concentrate  on  the  two  different  operational  aspects,  river  crossing  and  obstacle  denial 
operations.  [Ref.  p.  4b] 

1.  River  Crossing  Environment 

Riser  crossing  is  a  special  operation,  requiring  detail  planning  and 
information.  To  solve  this  problem,  first  I  will  use  the  high  level  data  flow 
diagram'  DI  D  1  to  define  logically  the  proposed  system,  and  later  expand  the  high  levci 
DI  D  to  develop  the  functional  level  DFD  to  define  the  functional  application  of  our 
proposed  system.  [Ref.  7:  p.  55] 
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A  DFD  shows  data  sources  and  destinations,  data  flows,  data  stores,  and 
processes.  A  DFD  uses  five  basic  symbols  to  form  a  picture  of  a  logical  system  in  this 
thesis.  A  square  defines  a  source  or  destination  of  data.  An  ellipse  represents  a 
process  that  transforms  data.  An  open-ended  rectangle  is  a  data  store.  A  rectangle 
represents  a  database.  And  an  arrow  is  used  to  identify  a  data  flow. 
a.  Define  the  Logical  Model 

In  order  to  solve  the  previous  mentioned  problem  and  satisfy  the 
requirement  specification,  we  need  to  know  who  will  cross  the  river  and  which  area  of 
the  river  will  be  used  for  this  operation.  Based  on  this  initial  information,  the  problem 
definition,  and  a  sequence  of  commander  and  staff  actions,  a  high  level  DFD  can  be 
developed  as  a  logical  model  of  our  system  for  river  crossing  operation  as  shown  in 
Fifiure  3.1. 
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Figure  3.1  High  Level  DFD  for  River  Crossing  Operation. 


In  the  first  step  of  this  DFD,  our  system  determines  whether  a  river 
crossing  operation  is  necessary.  If  the  output  of  this  process  is  that  the  river  crossing 
operation  is  necessary,  then  the  system  estimates  whether  is  it  possible  to  conduct  the 
operation  by  using  the  command's  engineer  units  and  their  equipments.  II'  possible, 
then  the  system  calculates  the  the  vehicle  crossing  rate.  If  either  insufficient  manpower 
or  equipment  is  found,  the  system  estimates  which  units  are  available  to  support  tins 
operation  and  what  equipments  are  available.  After  completing  the  high  level  1)1  I). 
we  have  to  examine  if  the  developed  DFD  can  solve  the  problems  or  not.  If  positive, 
then  we  expand  the  DFD  to  the  next  level  of  details;  otherwise  redeline  the  1)1  I)  to  trv 
again. 

b.  Develop  the  functional  level  DFD 

expanding  the  data  flow  diagram  through  functional  decompos;-.  a  o 
breaking  down  functions  into  its  subfunctions.  These  low  level  functions  ’hen  K’c  vne 
processes  on  a  new  data  flow  diagram,  complete  with  their  own  data  stores  ,.r.d  d.i’  . 
Hows.  [Ref.  p.  56] 

(1)  Functional  decomposition  of  Level  2:  Estimate  .W canty.  In  order  tv 
estimate  the  necessity  of  river  crossing  operation  in  this  level,  the  >wem.  as  s.ud 
earlier,  examines  if  there  exist  available  bridges  within  the  operational  houn Jar-  •  I  he 
system  can  also  estimate  the  capacities  of  these  bridges  based  on  the  stored  data.  1  he 
result  of  the  calculated  number  of  crossing  sites  is  stored  tor  other  processes  to  use 
later.  Thus  the  functional  decomposition  at  this  level  is  as  shown  in  Figure  2.2. 

(2)  Functional  decomposition  of  Level  3:  Estimate  Possibility.  At  this  level, 
the  system  has  to  estimate  the  possibility  of  a  river  crossing  operation,  using  the 
command's  engineer  units  and  their  equipments.  In  order  to  accomplish  this  function, 
first  the  system  needs  to  examine  the  organized  engineer  units  and  their  equipments  as 
an  output  of  this  process.  Also  the  system  has  to  select  the  required  crossing  sites 
based  on  the  previous  process.  After  selecting  the  crossing  sites,  the  required  number 
of  equipment  sets  have  to  be  calculated  as  in  the  process  2-5.  At  this  point,  the 
required  floating  bridges  can  be  calculated,  but  the  equipments  of  each  raft  site  can  not 
be  calculated  because  system  does  not  know  how  many  rafts  are  needed  at  each  raft 
site,  as  the  width  is  not  yet  known.  For  example,  we  need  one  raft  per  site  up  to  100m 
of  river  width,  two  rafts  per  site  up  to  200m.  and  three  rafts  per  site  up  to  2<)<»m  at 
each  crossing  she.  Therefore  we  need  one  more  subfunction  to  determine  the  number 
of  raft  for  each  raft  site  before  calculating  the  required  amount  of  equipments  for  raft 
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Figure  3.2  Decomposed  DFD  of  Estimate  Necessity  Process. 


Finally,  the  system  can  estimate  the  possibility  in  process  3-6  of  Figure 
3.3  by  comparing  the  required  equipment  sets  in  process  3-5  and  the  available 
equipment  in  process  3-2.  At  this  time,  if  the  available  equipment  is  enough  to  satisfy 
the  required  amount  of  equipment  calculated  by  process  3-5,  it  means  that  it  is  possible 
to  conduct  the  river  crossing  operation  without  additional  support  coming  from  other 
engineer  units  at  higher  headquarters.  But  if  it  is  not  enough,  then  the  commander  has 
to  make  a  final  decision  of  what  to  do.  The  entire  process  is  functionally  decomposed 
as  shown  in  Figure  3.3. 

(3)  Functional  decomposition  of  Level  4:  Examine  supporting  Units.  If  the 
commander  decides  that  he  needs  support  from  higher  headquarters  for  his  operation, 
the  system  proceeds  to  find  available  engineer  units  and  their  equipments.  It  then 
reestimates  the  feasibility  of  accomplishing  the  operation  under  the  new  circumstances. 
With  the  new  result  from  process  4-3  of  Figure  3.4  the  commander  can  then  make  a 
recommendation  to  his  higher  headquarters  where  a  final  decision  is  to  be  made.  The 
functional  decomposition  of  this  process  is  shown  in  Figure  3.4. 
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Figure  3.3  Decomposed  DFD  of  Estimate  Possibility  Process. 


(4)  Functional  decomposition  of  Level  5:  Generate  Crossing  Capacity,  f  rom 
the  result  of  the  above  4  functional  levels,  the  final  feasible  plan  of  the  river  crossing 
operation  is  generated.  The  system  next  begins  to  estimate  the  number  of  trips 
necessary  at  each  raft  site  (process  5-2  of  Figure  3.5).  It  also  calculates  the  assembly 
time  for  each  crossing  site,  the  transportation  capacity  for  vehicles  and  combat 
equipment  such  as  tanks,  armored  vehicles  etc.  and  the  time,  called  the  H-hour,  when 
everything  has  crossed  the  river,  Figure  3.5  shows  the  functionally  decomposed  DFD 
of  this  level. 

c.  Develop  the  Data  Dictionary  and  Algorithms 

Given  a  complete  data  flow  diagram,  we  have  a  reference  document 
specifying  the  entire  decision  support  system,  we  can  now  begin  to  consider  the  details 
such  as  the  data  elements  and  the  algorithms. 

To  allow  us  to  have  a  better  understanding  about  data,  we  make  use  of  a 
data  dictionary.  A  data  dictionary  is  a  collection  of  data  about  data.  The  basic  idea  is 


dement,  such  information  as  the  element  name,  description,  format,  source  and  use  is 
recorded.  The  data  dictionary  helps  the  analyst  to  organize  information  about  data, 
and  is  an  excellent  tool  for  communicating  with  the  user.  Additionally,  the  data 
dictionary  serves  as  a  memory  aid.  Key  information  must  be  recorded  for  each  data 
dement  [Ref.  p.  202]. 

A  simulated  data  dictionary,  introduced  by  Davis'  book  [Ref.  p.  29").  is 
to  be  used  in  this  thesis.  To  maintain  a  semblance  of  direct  access,  information  related 
to  each  data  dement  will  be  recorded  on  a  separate  3x5  filing  card  and  a  minimum 
amount  of  information  will  be  recorded  for  each  data  element  as  Table  1. 


TABLE  1 

SAMPLE  DATA  DICTIONARY 
NAME  ;  BROSITE 

DESCRIPTION  :  The  required  number  of  bridge  sites 
in  the  operational  boundary. 

FORMAT  :  Numeric  ;  1  digit 

LOCATION  :  Output  to  display  and  printer 


In  very  general  term,  every  computer  system  converts  input  data  into 
output  information,  and  the  algorithms  define  the  rules  for  these  conversions,  Without 
a  general  sense  of  the  algorithms  for  each  process  or  function,  we  can't  have  a  good 
idea  of  what  is  being  done  in  the  processes  in  the  system.  The  preliminary  algorithm 
descriptions  recorded  on  a  IPOdnput  Process  Output)  chart  as  shown  in  figure  3f> 
give  us  a  general  structure  that  can  be  refined  later  during  the  detailed  design  phase. 

2.  Obstacle/Denial  Environment 

An  obstacle  Denial  operation  is  also  a  major  mission  of  engineer  system.  If 
we  conduct  an  obstacle  denial  operation  during  a  retrograde  or  defensive  operation,  the 
commander  has  to  consider  the  whole  operation  carefully.  Ineffective  planning  o!  this 
operation  can  cause  severe  problems  if  a  counter  attack  is  to  be  conducted 
subsequently.  To  solve  this  problem,  we  first  develop  a  high  level  data  flow  diagram  to 
define  the  logica.  model  of  the  proposed  system.  Alter  that,  we  develop  the  '.unctior.u! 
lev  cl  DTD  to  define  the  functional  application  of  the  proposed  system  by  expanding 
’he  h.gh  level  DTD  into  more  details,  finally .  we  develop  the  data  dwtionurv 
algorithms  for  tins  system.  [Ref  n.  \\l 
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IPO  CHART 


SYSTEM  :  River  Crossing  Operation  Support  System 
PREPARED  EY  :  Jang,  Chang  Ki 

MODULE  :  CALCS ITE  ALGORITHM  DATE  :  APR/37 


CALLED  OR  INVOKED  BY: 
EXISTERG 


INPUTS: 

AREA  (coordinate) 


PROCESS: 

WHILE  NOT  EOF  DO 

A_RAFT  =  A_P.AFT  -  1,  B_RAFT 
A_BRG  =  A_BRG  -  1,  B_BRG 
END  WHILE 

ERGS ITE  =  A_BRG  +  B_BRG 
RAFTS ITE  =  A  RAFT  +  B  RAFT 


B_RAFT 
B  BRG 


a.  Define  the  Logical  Model 

As  previously  mentioned  in  the  system  requirement  specification  section, 
the  system  can  be  defined  logically  as  shown  in  Figure  3.7.  On  the  first  level  of  this 
diagram,  the  system  gets  its  initial  data  from  a  user  about  the  segment  of  a  road 
represented  by  the  coordinates  indicating  the  start  and  end  points,  the  road  number 
that  we  want  to  conduct  the  operation,  and  the  required  delay  time  to  the  enemy. 


Figure  3.7  High  Level  DFD  for  Obstacle'Denial  Operation. 


At  the  second  level  of  the  DFD,  the  system  estimates  what  obstacle  denial 
operations  arc  required  to  get  the  required  amount  of  delay  time.  If  more  obstacles  are 
r.oecssary,  the  system  selects  the  additional  targets  to  satisfy  the  commander's 
requirement.  In  order  to  select  additional  targets  in  this  process,  the  system  needs 
seme  additional  data  and  the  selection  criteria  as  contained  in  the  commanders 
p!  tuning  guidance.  More  detail  about  this  selection  critciia  will  be  described  in  the 
r.o\t  phase  of  developing  the  functional  level  DFD.  After  selecting  the  additional 
mr.’et,  the  system  evaluates  again  the  whole  process.  However,  it  may  not  be  enough 


when  all  the  designated  targets  in  this  segment  have  been  selected.  In  this  case,  we  go 
to  process  5  to  extend  the  road  segment  to  find  a  solution. 
b.  Develop  the  functional  level  DFD 

At  this  point,  the  high  level  data  flow  diagram  is  expanded  as  done  in  the 
river  crossing  operation  through  functional  decomposition. 


01  INITIAL  OATA 


02  ADDITIONAL 
OELAYTIME 


Figure  3.8  Decomposed  DFD  of  Estimate  Necessity  Process. 


(1)  Functional  decomposition  of  Level  2\  Estimate  Necessity.  In  order  to 
estimate  the  necessity  of  an  obstacle/denial  operation,  we  first  need  to  get  data  from 
the  user  and  the  database.  After  getting  the  data,  the  system  proceeds  to  search  the 
designated  targets  in  this  segment.  As  seen  in  Figure  3.8,  in  process  2-2,  the  system 
verifies  the  intended  targets  and  calculate  the  delay  lime. 

In  the  final  process  at  this  level,  the  system  evaluates  the  whole 
operation  based  on  the  calculated  delay  time  and  the  commander's  required  delay  time. 
If  the  calculated  delay  time  is  not  enough  for  satisfy  the  requirement,  we  have  to 
prepare  additional  operation  to  satisfy  it.  Thus,  the  high  level  DFD  can  be 
functionally  decomposed  as  shown  in  Figure  3.8. 

(2)  Functional  decomposition  of  Level  3:  Select  Target.  As  mentioned 
before,  at  this  stace,  the  svstem  selects  obstacle  targets  that  will  be  denied  or  emplaced 


For  example,  when  the  commander  has  selected  minimum  number  of 
targets  for  the  major  criterion  and  minimum  recover  time  for  the  minor  criterion,  the 


targets'  delay  ana  recover  times  are  as  shown  in  Table  2,  and  the  commander's  required 
delay  time  is  2  hours,  the  system  wall  select  the  target  B  and  C  in  process  3-2  of  Figure 
3.9.  It  can  easily  be  verified  that  this  combination  indeed  satisfies  all  the  stated 
conditions.  Functions  for  other  processes  are  as  shown  in  Figure  3.9. 

(3)  Functional  decomposition  of  Level  4:  Extend  Segment.  If  it's  not 
possible  to  satisfy  the  commander's  requirement  when  all  designated  targets  in  this 
segment  have  been  selected,  we  have  to  extend  the  segment  beyond  the  end  points  to 
find  other  targets.  The  result  of  this,  if  based  on  minimum  possible  extension  of  the 
segment  will  be  recommended  to  the  commander.  In  order  to  do  this  kind  of 
processing,  data  is  needed  from  the  initialization  process  to  determine  the  direction  of 
the  road  that  allows  an  extention  since  the  other  direction  is  presumably  occupied  by 
the  enemy  forces.  After  determining  the  direction  of  road,  the  system  can  then  search 
for  targets  to  satisfy  the  requirement.  Figure  3.10  shows  this  process  and  others  as 
well. 


Figure  3.10  Decomposed  DFD  of  Extend  Segment  Process. 
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IV.  SYSTEM  DESIGN  AND  IMPLEMENTATION 


A.  OVERVIEW 

The  proposed  system  that  I  try  to  develop  in  this  thesis  is  a  Decision  Dupport 
Dystem(DSS).  "The  term  decision  support  system  refers  to  a  class  of  systems  which 
support  the  process  of  making  decisions.  Decision  support  system  allows  the  decision 
maker  to  retrieve  data  and  test  alternative  solutions  during  the  process  of  problem 
solving"  [Ref.  S:  p.  368].  How  are  decisions  made?  The  answer  affects  the  design  of 
computer  based  information  systems  to  support  the  decision  making  process. 

In  the  previous  chapter,  analysis  has  just  been  completed.  The  functional 
requirements  of  the  desired  system  have  been  documented  with  a  data  flow  diagram,  a 
data  dictionary,  and  a  set  of  algorithm  descriptions.  The  time  has  come  to  consider 
how  to  do  it.  and  thus  the  system  design  process  begins. 

"The  objective  of  system  design  is  to  produce  an  appropriate  physical  model  of 
the  system,  called  system  flowchart,  within  the  context  of  a  complete  system  and  to 
determine  how  the  system  will  be  implemented.  In  the  structured  approach  to  systems 
analysis  and  design,  we  begin  by  constructing  the  logical  model,  often  using  data  flow 
diagram  as  a  tool.  During  system  design,  this  logical  model  must  be  converted  to 
physical  form"  [Ref.  7:  p.  326],  At  first,  we  develop  an  appropriate  system  flowchart 
that  represents  the  overall  system,  and  the  database,  which  is  one  component  of  the 
overall  system,  is  designed.  Finally,  we  will  develop  a  set  of  specification  for  those 
programs  using  Hierarchy  plus  Input  Process  OutputiHIPO)  technique. 

During  the  program  design  process,  if  we  can  determine  what  our  minds  do  at  a 
given  stage  of  any  decision  making  process,  we  can  easily  find  in  this  program  design  a 
section  that  corresponds  to  an  equivalent  aspect  of  human  intelligence.  All  the 
elements  that  comprise  the  human  decision  making  process  -  goals,  facts,  rules, 
inference  mechanism,  and  pruning  -  must  be  collected  in  a  computer  program  for  it  to 
be  properh  described  as  possessing  Artificial  Intelligence!  A I ).  [Ref.  10:  p.  10] 

B.  DEVELOP  THE  SYSTEM  FLOWCHART 

In  this  Section.  I  will  identify  the  individual  physical  components  of  the  system. 
Contents  cf  these  black  box  will  be  planned  in  the  next  section-database  design  and 
program  design  phase. 
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1.  Physical  Components  of  the  System 

In  order  to  develop  the  system  flowchart,  we  first  need  to  identify  the  physical 
components  of  the  system  as  shown  in  Table  3.  The  proposed  system  will  access  the 
database  through  the  Data  Base  Management  Systcmi  DBMS)  and  also  wiil  need  initial 
data  to  process  each  operation.  It  will  write  a  variety  of  reports  phase  by  phase  o: 


PHYSICAL  COMPONENTS  OF  THE  SYSTEM 


Programs 


Manual  procedures 


Data  entry 

Initialization 

Intelligent  System 

River  crossing  operation 
Obscacle/Deniai  operation 

Data  collection 
Making  plan 

Software 

Files 

Forms 

D3MS 

Data  Base 

Reports 

A  data  entry  program  will  maintain  the  database:  to  add  data  to  the  database, 
to  update  data  which  is  in  the  database,  and  to  delete  data  from  the  database.  A  data 
initialization  program  will  initialize  the  operation  environment  for  each  operation,  and 
wiil  siore  it  in  the  on-line  storage  for  iater  use.  River  crossing  program  and 
obstacle  denial  program  are  the  intelligent  part  of  the  proposed  system  that  will 
generate  the  report  based  on  the  available  data  in  the  system.  A I  techniques  allow  the 
construction  of  a  program  in  which  each  piece  of  the  program  represents  a  highly 
dependent  and  identifiable  step  toward  the  solution  of  a  problem  or  set  of  problems. 

2  System  Flowchart 

A  system  flowchart  is  a  traditional  tool  for  describing  a  physical  system.  The 
basic  idea  is  to  provide  a  symbol  to  represent,  at  a  black  box  level,  each  discrete 
component  :n  the  system  -  programs,  files.  1'orms,  procedures,  and  so  on. 


A  data  flow  diagram  presents  a  rather  abstract  picture  of  the  system.  In 
contrast,  the  system  flowchart  is  more  concrete.  Specific  programs  or  procedures 
replace  the  generalized  process,  and  specific  files  or  databases  replace  the  data  stores, 
(diver.  the  flowchart,  it  is  possible  to  visualize  how  the  system  will  be  implemented. 

1  he  system  flow  diagram  identifies  each  of  the  discrete  components  of  the  system.  For 
planning  purpose,  these  components  can  be  attacked  one  at  a  time  -  the  divide  and 
conquer  approach.  [Ref.  12:  p.  87] 

The  system  flowchart  of  the  proposed  system  graphically  illustrates  the 
physical  system.  As  shown  in  Figure  4.1,  each  symbol  defines  at  the  black  box  level 
one  of  the  discrete  components  thaf  make  up  this  system,  and  the  flowlincs  define  the 
logical  path  through  the  system.  Thus  the  system  flowchart  as  shown  in  Figure  4.1  is 
generated,  based  on  the  physical  components  of  the  system  and  data  flow  diagram 
dc".  eloped  in  the  previous  chapter. 


Figure  4.1  System  Flowchart 


C.  D  ATABASE  DESIGN 


1.  Overview 

A<  I  mentioned  before,  the  proposed  system  has  a  database  as  a  part  of  the 
physical  components  of  the  system.  In  the  proposed  system,  the  database  is 
maintained  with  data  to  satisfy  the  applications  for  each  operational  environment, 
namely  river  crossing  operation  and  obstacle  denial  operation. 

In  order  to  accomplish  our  goal,  two  major  tasks  are  accomplished  during  the 
design  of  a  database-oriented  system.  One  task  is  to  define  the  database  structure,  and 
the  other  is  tc  design  the  application  programs.  Designing  the  application  programs 
will  be  discussed  in  the  next  section,  program  design. 

Database  design  is  an  intuitive  process.  Typically,  it  is  an  iterative  process. 
During  each  iteration,  the  goal  is  to  get  closer  to  an  acceptable  design.  Thus  a  design 
is  developed  and  then  reviewed.  Furthermore,  the  design  process  is  divided  into  two 
phases,  first,  the  logical  structure  of  the  database  that  is  a  DBMS-independent 
database  design  is  developed.  Once  the  logical  structure  has  been  defined,  it  is 
transformed  into  physical  form  that  conforms  to  the  features  of  the  DBMS  to  be  used. 
In  this  wav  the  logical  structure  is  mapped  into  the  data  description  facilities  provided 
by  the  DBMS  product. 

2.  Logical  Database  Design 

a.  Procedures  for  Logical  Database  Design 

The  major  steps  in  the  logical  design  process  are  divided  into  five  phases. 
First,  the  data  dictionary  is  processed  and  the  data  to  be  stored  is  identified  and 
segregated.  Next,  the  terms  used  for  the  data  are  to  be  clarified  because  there  may  be 
hundreds  or  thousands  of  data  items  in  the  logical  schema  which  is  developed  in  the 
next  phase.  The  third  step  in  the  design  process  is  to  develop  the  logical  schema  by 
defining  records  and  relationships.  Records  are  defined  by  determining  the  data  items 
thev  will  contain.  And  the  relationships  between  these  records  is  to  be  determined  in 
this  phase.  The  next  step  in  logical  database  design  is  to  define  the  processing  of  the 
database.  But  this  has  already  been  defined  in  the  system  analysis  phase.  Mere, 
however,  it  will  be  defined  in  more  detail  for  the  program  design  phase.  1  inally,  the 
logical  schema  and  user  views  arc  examined  in  light  of  the  requirements  and  program 
descriptions.  To  be  effective,  the  design  review  must  follow  stringent  guidelines. 


From  the  result  of  these  processes,  the  logical  database  records  and 
relationships  among  them  are  generated  as  an  output  of  the  logical  database  design 
process  as  expressed  in  the  form  of  data  (low  diagrams  and  policy  statements,  and  the 
data  dictionary  will  become  the  input  to  the  logical  database  design. 
b.  Develop  the  Logical  Database  Records  and  Relationships 

A  logical  database  design  specifies  the  logical  format  of  the  database.  The 
records  to  be  identified  and  maintained,  their  contents,  and  their  relationships  are 
specified. 

(l'l  Logical  database  records.  In  this  section,  logical  database  records  are 
identified  to  satisfy  the  required  operation  and  the  contents  of  these  records  are 
defined.  The  proposed  system  has  11  data  records  to  accomplish  the  required 
functions,  as  shown  in  Table  4.  The  contents  cf  these  records,  names  of  fields,  and 
their  formats  are  specified.  For  example.  River  Object(RlV_OBJ)  record  contains  data 
about  all  objects  such  as  bridges  and  river  crossing  sites  of  a  certain  river.  So 
RIV_OBJ  record  should  contain  the  name  of  river,  location  of  the  objects  and  type  of 
object  etc.  Also,  available  equipment  of  each  unit(L'NlTEQP)  record  represents  how 
many  river  crossing  equipments  are  being  equiped  in  each  engineer  unit.  So  it  contains 
the  information  about  the  unit  name,  the  amount  of  equipments  that  are  available  for 
the  operation,  and  so  cn. 

(2)  Relationship  between  records.  As  stated  several  times  already,  the 
essence  of  a  database  is  the  representation  of  record  relationships.  These  relationships 
are  specified  during  logical  design.  Figure  4.2  shows  relationships  between  previously 
defined  data  records. 

As  shewn  in  Figure  4.2,  several  river  crossing  means  can  be  operated 
at  the  same  crossing  site  and  also  different  river  crossing  means  can  be  operated  at  the 
several  crossing  sites  simultaneously.  Therefore  the  relationship  between  crossing  sites 
and  river  crossing  means  is  many-to-many  relationship  [Ref.  13:  p.  121].  Moreover, 
there  may  not  be  any  relationship  between  BRIDGES  and  TARGETS  because  some 
bridges  can  not  be  a  target  to  deny,  if  there  exist  by-passes  around  the  bridge  or  if  it  is 
easy  to  overcome,  even  when  a  bridge  is  blown  up.  Since  a  bridge  can  be  on  only  one 
road  cr  one  river,  there  exists  a  one-to-one  relationship  between  BRIDGE'S  and 
RIV  OBJ  or  RD  OBJ. 
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TABLE  4 

LOGICAL  DATABASE  RECORDS 


RECORDS  NAME 

DESCRIPTION  OF  RECORDS 

RI7_OEJ 

All  objects  on  the  river  such  as  bridges 
and  river  crossing  sites. 

RD_03J 

All  objects  on  the  road  such  as  tunnels, : 
bridges,  minefields,  and  road  craters. 

TARGETS  i 

Targets  that  are  Dlannea  to  deny  or  1 

enpiace. 

BRIDGES 

Characteristics  of  bridges. 

TUNNELS  i 

Characteristics  of  tunnels. 

MINEFLDS 

- - - 1 

Mine  fields  that  are  that  are  planned.  I 

RDCRATER 

i 

Planned  road  crater  on  the  road.  ! 

CROSSITE 

— - 1 

Characteristics  of  the  river. 

CRCSSEQ? 

Characteristics  of  the  river  crossing 
equipments. 

UNITEQP 

Available  equipment  of  engineer  units. 

ASSIGN 

Status  of  unit  assignment. 

'■  Physical  Database  Design 

a.  Physical  Database  Design  Process 

The  second  stage  of  database  design,  called  physical  design,  is  a  stage  of 
transformation.  The  logical  schema  is  transformed  into  the  particular  data  constructs 
that  are  available  for  the  DBMS  to  use.  Whereas  the  logical  design  is  DBMS- 
independent.  the  physical  design  is  very  much  DBMS-dependent. 
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only  a  portion  of  the  database,  the  logical  design  must  specify  what  user  groups  will 
view  winch  portions  of  the  database. 

b.  Develop  the  Physical  Schema 

[  1 t  Define  the  Fields  and  Key.  In  this  process.  I  will  define  the  contents  of 
each  record,  the  name  and  format  of  each  record  field,  the  domains  and  the 
constraints,  and  also  the  keys  of  the  database  records. 

Let  us  look  at  database  records  RIYOBJ  and  RD  OBJ  that  are 
already  defined  in  the  logical  database  design  phase.  These  records  represent  bridges 
and  river-crossing-sites  on  the  river  or  obstacles  such  as  bridges,  and  tunnels  on  the 
road  that  have  been  designated  as  targets.  In  the  record  TARGETS.  TNT.'Mt Target 
Number!  or  LOC  are  keys  for  this  record,  because  TNL  .M  will  identify  a  target.  LOG 
is  a  key  when  we  find  targets  within  certain  segment  of  a  road.  Therefore  records, 
contents  of  records  can  be  defined  as  shown  in  Table  5. 

(. 2 1  Define  the  Field  Format  and  Domain.  Next,  we  define  the  format  and 
domain  of  field  value  as  shown  in  Table  6.  In  this  table,  LOC  is  represented  by  2 
alphabetic  characters  at  the  begining  of  the  field  value  followed  by  6  numeric  digits. 
Two  alphabetic  characters  represent  the  name  of  a  coordinate  block.  Tor  example. 
T'-XXX-Il  of  TNl’M  represents  the  11th  target  of  the  10th  Corps.  So  XXX 
represents  the  corps  command  and  "XX"  represents  the  division  command.  The 
ARMY.  CORPS.  D1Y.  BRGD.  LBN.  BCO.  I  BCO  of  l  NTT  represent  field  army, 
corps,  division,  brigade,  engineer  battalion,  bridge  company,  and  floating  bridge 
company  respectively,  furthermore.  1:2:3  of  minefield  density  represents  the  density  of 
antitank  mine,  fragment  antiperson  mine,  and  blast  antiperson  mine  respectively. 

<3)  Define  the  Constraints.  As  the  requirements  are  evaluated  and  the 
design  process  progresses,  constraints  on  data  items  will  be  identified.  These 
constraints  are  'limitations  on  the  values  that  the  data  in  the  database  can  have.  Three 
type  of  constraints  are  common,  field  constraints  limit  the  value  that  a  gb.en  data 
item  can  have.  Intrareccrd  constraints  limit  values  between  fields  within  a  given 
record.  And  interrecord  constraints  limit  values  between  fields  in  dilierent  records 
'Re.i  13:  p.  1"TJ.  Table  7  shows  an  example  for  interrecord  constraints 


D.  PROGRAM  DESIGN 

At  this  time  the  system  fowchar's  inr.e  cist  been  completed  and  the  physu.nl 
components  making  up  the  system  -  programs,  files,  forms,  manual  procedures,  and 
software  -  ’nave  been  identified  How.  spew.fkn'.lv.  should  the  s\ stem  be  implemented 


-to 


COM'. MS  or  RLCORD 


RECORDS 

FIELDS 

KEY 

RIV_OEJ 

LCC:  Location 

OTYPE:  Object  type 

RNAME: 

River  name 

LCC 

RD_CB J 

LOC:  Location 

OTYPE:  Object  type 

RNUM:  Road  number 

LOC 

.  TARGETS 

TNUM:  Tarcet  number 
TTYFS:  Tarcet  tvpe 
STATE:  Target  state 

LOC:  Location 

DTIME:  Delay  time 

TNUM 

LOC 

BRIDGES 

LCC:  location 

LENGTH:  Brg. length 
CLASS:  Brg.  capacity 

BNAME: 

WIDTH: 

STATE: 

Bridge  name 
Brg.  width 

Brg.  state 

LOC 

TUNNELS 

LCC:  Location 

WIDTH:  Tunn.  width 

LENGTH: 

HEIGHT: 

Tunn.  length 
Tunn.  height 

LCC 

MI ME ELDS 

TNUM:  Target  number  DENSITY:  Density  of 
FRONT:  Front  length  mine  field 
DEPTH:  Length  from  front  to  rear 

TNUM 

RDCRATER 

TNUM :  Target  number 
DEPTH:  Front  to  rear 

WIDTH: 

Crater  width 

TNUM 

CROSS  I TE ' 

LOC:  Location  WIDTH:  River  width 

DEPTH:  River  depth  VELO:  Water  velocity 

0B3T:  Water  obstacles 

LOC 

CROSSEQP 

MEANS:  Tyne  of  EQP. 
CLA.SS:  Cabacity 

NRAFT:  Rafts/set 

LENGTH: 
AT I ME: 

1  set  length 
Assemble  time 

MEANS 

UNITEQP 

UNIT:  Name  of  unit 
LTR:  Light  raft 

AFB :  Foot  bridae 

M4T6:  Float  bridge 

UNIT 

ASSIGN 

UNIT:  Name  of  unit 
DATE:  Attached  date 

EE LONG: 

Belong  unit 

UNIT 

based  on  the  system  flowchart,  physical  components  of  the  system,  and  data  P.o 
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IN  niRRhCORD  CONSTRAINTS 


r:v_obj. loc 

RD_OBJ. LOC 

TARGETS.  TNUM 
UNITEQP.  UNIT 


subset  of 

subset  of 

subset  of 
subset  of 


BRIDGES.  LOC 
CROSSITE.  LOC 
TARGETS.  LOG 

TARGETS.  LOC 
BRIDGES.  LCC 
TUNNELS.  LCC 

MINEFLDS.  TNUM 
RDCRATER.  TNUM 

ASSIGN. UNIT 


; crams.  In  this  section,  specific  physical  components  arc  identified,  and 

crrofition.ships  defined  using  the  HiPO  technique. 

The  first  step  in  designing  the  program  is  to  draw  a  high-level  hierarch}  c 
we  already  discussed  in  Chapter  III.  the  proposed  system  has  two  operati 
vi.-pr.ments  -  river  crossing  and  obstacle  denial  operations  -  and  also  needs  data 


% 


management  functions  to  add,  delete,  and  update  the  data  in  the  database.  Thus  this 
system  can  be  divided  into  two  subsystems,  river  crossing  and  obstacle  denial,  and  the 
database  management  system  will  support  these  two  subsystems. 

I.  Subsystem  1  :  River  Crossing  Operation 

Based  on  the  data  flow  diagram  in  Figure  3.1,  a  high-level  hierarchy  chart 
showing  the  primary  functions  of  the  system  for  the  river  crossing  operation  is  defined 
as  shown  in  Figure  4.3. 


Figure  4.3  High-level  Hierarchy  Chart  of  Subsystem  1. 

This  subsystem  has  five  modules,  Get  Data,  Examine  Necessity,  Examine 
Possibility,  Survey  the  Supporting  Units  and  Generate  the  Vehicle  Crossing  Capacity. 
The  Riser  Crossing  Operation  subsystem  begins  with  Process  Get  Data.  By  executing 
this  process,  the  system  gets  the  initial  data  about  the  name  of  the  river  crossing 
command,  the  name  of  the  river  to  cross,  and  the  river  crossing  area  as  represented  by 
the  coordinates.  After  executing  this  process,  it  returns  the  control  to  the  main  control 
module,  river  crossing  system.  Next,  the  main  control  module  transfers  the  control  to 
the  Examine  Necessity  module  which  estimates  the  necessity  of  the  river  crossing 
operation.  Then  it  is  back  to  the  main  module,  which  invokes  the  next  lower  level 
m  :  dole  and  so  on. 

By  itself,  the  initial  hierarchy  chart  is  not  very  useful  because  it  is  very  general. 
Therefore,  we  need  to  break  down  each  function  to  a  lower  level  of  detail.  As 
mentioned  before,  the  process  is  'mown  as  functional  decomposition.  [Ref.  p.  329j 
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a.  Module  1  :  Examine  Necessity 

This  module  determines  whether  the  river  crossing  operation  is  necessary  or 
not.  To  perform  this  function,  it  invokes  the  Search  Bridge  function.  First  this 
function  performs  a  'join''  operation  with  RIV_OB.J  and  BRIDGFS  relations  and  finds 
the  available  bridges  in  this  area  with  the  given  initial  data.  In  order  to  find  existing 
bridges  in  this  area,  the  module  determines  the  direction  of  the  river.  The  coordinates 
are  two  dimensional  value,  but  in  the  system  we  need  only  X-axis  or  Y-axis  value  to 
find  the  bridges  or  crossing  sites.  After  finding  the  available  bridges,  the  module 
invokes  the  Verify  Bridge  function  to  check  the  class  of  bridge  and  to  estimate  the 
capability  of  that  bridge.  It  then  calculates  the  required  number  of  crossing  sites  based 
on  this  result.  If  there  is  no  bridge  available  in  this  area,  then  we  need  to  make  one 
bridge  site  and  three  raft  sites  in  each  area.  But  if  there  exist  usable  bridges  and  the 
class  of  the  bridges  is  over  45,  then  we  don't  have  to  make  a  bridge  because  heavy 
equipment  such  as  tank  can  cross  through  this  bridge.  But  if  the  class  is  between  20 
and  45,  then  the  system  assumes  that  the  capability  of  each  bridge  in  this  class  is  two 
times  that  of  the  rafts.  Therefore,  the  required  number  of  raft  site  will  be  reduced  by 
one  for  each  bridge  in  this  class.  Finally,  the  module  estimates  the  necessity  of  the 
operation  based  on  the  calculated  crossing  sites.  Therefore  we  can  decompose  this 


b.  Module  2  :  Examine  Possibility 

When  the  River  Crossing  Operation  Subsystem  gets  control  back  from  the 
Module  1.  Examine  Necessity,  it  invokes  the  next  module.  Examine  Possibility,  to  see  if 
riser  crossing  operation  is  necessary  from  the  result  of  Module  !.  This  module 
estimates  the  possibility  of  the  river  crossing  operation,  using  the  command's  engineer 
mats  and  their  equipments.  In  order  to  estimate  the  possibility,  several  functions  such 
as  Select  Crossing  Sites,  Unit  EQPs,  and  Calculate  Required  Equipments  are  needed. 

1  :r<.  tine  module  has  to  select  the  crossing  sites  of  the  database.  To  select  crossing 
sites,  the  module  first  surveys  all  the  crossing  sites  in  this  area,  then  sort  them  by  width 
of  the  river,  and  finally  selects  the  crossing  sites  that  have  minimum  widths  and  also 
with  water  velocity  not  over  2  mps( meter  per  second).  The  system  has  to  consider  the 
amount  of  equipments  available  for  this  operation.  To  do  this,  it  examines  the 
participating  engineer  units  from  the  database  file  called  ASSIGN.  After  examining 
tluwe  engineer  units,  the  system  surveys  the  available  equipments  of  these  unit  from  the 
database  file  called  L'NTTEQP.  Next,  the  module  calculates  the  equipments 
requirement  for  these  sites.  Before  calculating  equipments,  the  module  has  to  estimate 
the  number  of  rafts  per  each  raft  site,  which  depends  on  the  width  of  the  river.  Finally, 
the  module  estimates  the  possibility  by  comparing  the  required  equipments  to  the 
available  equipments.  Therefore  we  can  decomposed  this  module  as  in  Figure  4.5. 


Figure  4.5  Decomposed  Possibility  Module. 
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c.  Module  J  :  Search  Supporting  i'nits 

From  the  result  of  Module  2.  the  system  searches  available  supporting 
units,  i;'  the  river  crossing  operation  is  impossible  without  ether  engineer  units'  support 
and  their  equipments.  The  s> stem  invokes  this  module  to  find  the  available  engineer 
units  and  equipments.  First,  the  module  determines  the  name  of  high-level  command 
cf  the  river  crossing  command  from  the  database  file  called  ASSIGN.  Next  the 
module  determines  which  units  are  assigned  to  the  high-level  command,  and  alter  that, 
it  determines  which  engineer  units  are  assigned  to  these  units,  f  inailv  it  determines  the 


assigned  engineer  units  and  their  equipments. 

(/.  Module  4  :  Generate  Crossing  Capacity 

The  system  invokes  this  module  to  generate  the  output  to  show  how  main 
vehicles  can  cross  the  river  every  hour  and  when  the  command  and  its  vehicles  and 


equipments  finish  crossing' H-hourc  In  order  to  do  this,  the  module  calculates  hew 
many  trips  are  possible  per  hour  at  each  crossing  sites  by  raft  and  also  calculates  the 
assembly  time  for  the  rafts  and  floating  bridges.  Based  on  these  calculations,  the 
module  generates  the  crossing  capacity.  Figure  4.6  shows  the  decomposed  riser 
crossing  operation  subsystem.  The  detailed  algorithmes  are  given  in  Appendix  A. 
which  shows  the  Pseudo  Programming  of  the  proposed  system. 

2.  Subsystem  2  :  Obstacle/Denia!  Operation 

We  have  already  developed  the  logical  model  of  this  system  in  Chanter  Ill.  In 
this  section,  we  convert  the  logical  model  of  this  system  to  physical  model.  Therefore 
we  can  develop  a  high-level  hierarchy  chart  for  this  system  based  on  the  data  flow 
diagram  and  system  flowchart  as  in  figure  J.7. 

This  subsystem  has  four  functions.  Get  Data.  Examine  Necessity.  Select 
1  argots,  and  Extend  Segment  of  operational  boundary.  Further,  this  subsystem  begins 
with  initial  data  about  road  number,  segment  of  road  and  required  amount  of  delay 
time  to  prepare  the  next  operation.  This  Rind  of  data  will  be  given  to  the  subsystem 
through  the  Get  Data  module.  After  receiving  the  data,  the  subsystem  invokes  the 
1  x  unuie  Necessity  module  to  estimate  the  necessity  of  operation  under  the  current 
situation.  In  order  to  estimate  it,  this  module  needs  several  functions  such  as  Search 
I  tree:-  : unction  that  finds  the  designated  targets  in  the  operational  boundary.  Survey 
large:  function  which  surveys  the  unemplaced  or  undenied  targets  among  the  targets 
that  are  .dread;,  found  by  the  previous  function,  and  Calculate  Delay  Time  function. 


After  cettmc  the 


a!  data,  the  obstacle  denial  operation  invokes  the  Examine 
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Figure  4.7  High  Level  Hierarchy  Chart  of  Subsystem  2. 

When  the  calculated  delay  time  is  not  enough  to  satisfy  the  commander's 
requirement,  the  system  call  to  the  next  module  Select  Target  becomes  necessary.  This 
module  selects  the  additional  targets  that  will  be  emplaced  as  obstacles.  At  this  time, 
the  commander  s  selecting  criteria  to  select  the  target  as  already  discussed  in  the  system 
analysis  phase  is  required  when  the  available  delay  time  in  this  segment  is  not  enough 
for  the  commander's  requirement,  the  system  finally  calls  the  Extend  Segment  module 
in  order  to  extend  the  operational  boundary  for  this  operation.  This  module  is  also 
functionally  decomposed  into  several  functions  such  as  Determine  Road  Direction  and 
Search  Target.  The  Determine  Road  Direction  Function  examines  the  direction  of 
road  to  extend  the  road  segment.  Although  the  coordinates  are  two  dimensional  value, 
X-axis  and  Y-axis,  we  need  only  one  dimensional  value  to  extend  the  road  segment  and 
search  target.  But  sometimes  we  need  both  of  X  and  Y  value.  From  the  result  of 
these  modules,  the  system  can  be  functionally  decomposed  as  in  Figure  4.8.  Appendix 
A  dunes  a  detailed  algorithm  of  this  system. 

F.  SYSTEM  IMPLEMENTATION 

The  structured  system  analysis  and  design  for  the  proposed  system  have  been 
di'-ctiN'-ed  in  the  previous  sections.  Specifications  for  the  programs  have  been  written. 
'I  lie  time  has  come  to  discuss  the  implementation  of  the  proposed  system,  as  the  final 
s*ep  of  the  structured  system  analysis  and  design  methodology. 

Implementation  is  simply  the  process  of  carrying  out  the  specified  design.  It  is 
concerned  with  coding,  documenting,  and  debugging  the  programs.  In  addition,  during 
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Figure  4.8  Decomposed  Obstacle  Denial  Subsystem. 

implementation  operating  procedures  are  written.  The  need  for  training  is  an  often 
overlooked  aspect  of  system  implementation.  Further,  system  test  is  conducted  in  this 
step.  [Ref.  7:  p.  100] 

The  object  of  structured  programming  is  to  generate  programs  that  are  easy  to 
understand,  and  hence  easy  to  debug  and  maintain.  The  basic  principle  of  structured 
programming  is  akin  to  the  military  strategy  of  divide  and  conquer.  A  program  is 
or; 'ken  into  small,  independent  single  functional  modules  which  are  clear  and  easy  to 
of  "'.'.'.  These  modules  are  themselves  composed  of  even  smaller  blocks,  such  as  the 
sequence,  decision,  and  repetition  structures. 

!  lie  river  crossing  operation  subsystem  of  the  proposed  system  has  been 
implemented  in  a  microcomputer  using  dBASE  III  Plus,  as  shown  in  Appendix  B. 
Fa-h  module  of  this  system  is  coded  by  top-down  implementation  technique  using  the 
hicrurcnical  chart  that  has  been  developed  in  the  system  design  phase. 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  goals  o:'  this  thesis  were  to  maintain  and  analyze  information  related  to  the 
Army  Engineer  Operation,  and  to  provide  information  to  the  commander  and  his  stalls 
in  order  to  support  their  decision  making  process  during  the  planning  phase  of  an 
engineer  operation. 

To  develop  this  system,  the  author  first  described  the  operational  concepts  of  the 
engineer  system  under  the  combined  arms  team  as  the  background  of  this  system. 
After  that,  the  author  analyzed  the  current  system  of  the  Korean  Army  Engineer 
Operation  to  define  the  problems  and  defined  the  operational  environments  in  order  to 
determine  the  functions  of  this  system  to  soive  the  problems.  During  the  analysis  and 
design  process  cf  this  system,  the  structured  system  analysis  and  design  methodology 
and  artificial  intelligence  technique  were  used.  A  more  general  rule-based  system 
architecture  has  not  been  used  because  of  the  restricted  time  to  do  the  thesis,  the  desire 
to  see  and  learn  what  appropriate  information  and  system  may  be  needed,  and  the 
belief  that  an  operational  system  necessarily  requires  a  complete  re-do  from  tins 
learning  experience,  finally,  the  system  was  implemented  as  a  prototv  pc  with  the 
system  JBASE  111  Plus. 

The  Engineer  Operation  Support  System)  EOSSt  determines  the  necessity  and 
pcssir:’:;-.  of  the  engineer  operations,  river  crossing  and  obstacle  denial  operations, 
during  the  planning  phase  of  an  operation.  The  commander  and  stall  can  vac  their 
decision  making  time  using  the  result  of  this  system  as  an  output.  In  addition,  tiiev 
gain  rei;.fs;!ity  of  data  and  information  related  with  engineer  operation  by  using  tins 
■'■•stem.  To  accomplish  these  objects,  relevant  data  and  information  must  be 
maintained  accurately  in  the  database  file. 

Through  the  study  of  this  system,  the  author  achieved  the  primary  goals  of  this 
study  by  combining  the  knowledge  of  army  operations,  specifically  army  engineer 
operations,  structured  system  analysis  and  design  methodology,  and  programming 
tecr.niques.  This  system  is  tire  most  useful  for  the  operations  in  the  division  and  corps 
commands,  but  it  can  be  used  for  the  field  Army  Command  or  Army  He.idc  .  ;.te:s  : 


B.  RECOMMENDATIONS 


In  this  thesis,  the  author  implemented  the  river  crossing  operation  with  dBASI 
III  Pius  as  an  example.  But  dBASI:  III  Plus  programs  are  slower  than  complied 
programs  using  C  or  Pascal.  To  improve  the  performance  of  this  system,  the  system 
has  to  he  rewritten  in  C  or  Pascal  or  some  other  more  powerful  logical  programming 
languages  'ike  Prolog,  and  also  the  obstacle  denial  operation  part  has  to  be 
implemented  in  the  future.  Furthermore,  tactical  situations  such  as  the  situations  of 
the  friendly  and  the  enemy  forces,  fire  support  plan,  movement  plan.  etc.,  have  to  be 
included  ;r.  the  future  study  of  this  system:  here  in  this  system  only  the  engineer 
environment  of  the  combined  arms  team  has  been  considered. 


APPENDIX  A 
ALGORITHMS 


River  Crossing  Operation  Subsystem 


a.  Get  Data  Module 

Input  Data 

MUM IT  :  River  crossing  command 
MRUAME  :  Marne  of  river 

LEFT  :  Coordinate  of  leftmost  of  the  crossing  site 
MIDDLE  :  Coordinate  of  the  center  of  the  crossing  site 
RIGHT  :  Coordinate  of  rightmost  of  the  crossing  site 

b.  Examine  Necessity  Module 

***  Search  available  bridge  in  area  A  and  B  *** 

AREA  =  'A',  LOCI  =  LEFT,  L0C2  =  MIDDLE 
join  with  RIV_05J  and  BRIDGES  to  TEMP 

for  RIV_OB J . OTYPE  =  '  BRC-E  '  ,  RIV  OBJ.RMAME  =  MRNAME 
RIV_C3 J . LOC  =  3RIDGES . LCC 
while  .T.  do 

select  LOC,  BNAME,  CLASS 
from  TEMP 

where  LOCI  <=  TEMP. LOC  <=  L0C2 ,  TEMP. STATE  =  'AVAIL1 
insert  to  TEMPI 
if  AREA  =  -B1  then  exit  loop 
else  AREA  =  'B!,  LOCI  =  MIDDLE,  L0C2  =  RIGHT 
endif 
end  while 

***  Calculate  Crossing  Site  *** 

3RG  =  1  :  Bridge  site 

RAFT  =3  :  Raft  site 

AREA  =  'A' 
while  net  eof(TEMP) 

if  TEMP. CLASS  >=  45  then  BRG  =  BRG  -  1 
else  if  TEMP. CLASS  >=  20  then  RAFT  =  RAFT  -  2 
else  RAFT  =  RAFT  -  1 
endif 

endif 
end  while 

if  BRG  <=  0  then  BRG  =  0 
endif 

if  RAFT  <=  0  then  RAFT  =  0 
er.cif 

£  $  *■  ir?,3  ts  NsCSSSIl^  ^  ^ 
if  BRG  >  0  or  RAFT  >  0  then 

"River  Crossing  Operation  is  Necessary" 
else  "River  Crossing  Operation  is  not  necessary" 
endif 

c.  Select  Crossing  Sites 

***  Selecting  Crossing  Sites*** 

AREA  =  A1,  LOCI  =  LEFT,  L0C2  =  MIDDLE 

-om  with  P.IVJjEJ  and  CROS5ITE  TO  TEMP 

for  RI7_0BJ. OTYPE  =  'SITE1,  RI7JDE J . RNAME  =  MRNAME 
RI7_C5 J • LOC  =  C?  OSS ITE . LOC 
while  .7.  do 

while  not  eof ( TEMP ) 

select  LOC,  WIDTH,  VELC ,  OEST 
from  TEMP 

where  LOCI  <  =  TEMF.LOC  <=  LOC2 
insert  to  .EMP1 
end  while 


sort  TEMPI  with  TEMPI .WIDTH(ascendinq  orders 
while  not  ecf (TEMPI)  or  (  BRG  <>  Oana  RAFT  <>  0  ) 
select  LOC,  WIDTH 
from  TEMPI 
where  minimum  WIDTH 

VETO  <"=  2.0,  OEST  =  'none' 
insert  to  SELECTED 
ERG  =  ERG  -  1 ,  RAFT  =  RAFT  -  1 
end  while 

if  AREA  =  ■ B 1  then  exit  loop 
else  AREA  =  ’ B ' ,  LOCI  =  MIDDLE,  L0C2  =  RIGHT 
e.ndif 
end  while 

***  Survev  Oraa.nized  Engineer  Units  and  Equipments  *** 
join  with  ASSIGN  AMD  UNITEOP  to  TEMP 
select  UNIT,  AFB ,  LTR,  M4T& 
from  TEMP 

where  TEMP. UNIT  =  MUNIT 
insert  to  TEMPI 
while  net  eof(TEMP) 

MAPS  =  MAFE  +  AFB 
MLTR  =  MLTR  +  LTR 
NM4T6  =  KM4T6+  M4T5 
end  while 

Calculate  Required  Equipment  *** 

RAFB,  RLTR,  RM4T6  Required  amount  of  equipments 

while  noc  eof (SELECTED ; 

if  MEANS  =  "BRGE"  then 

RM4T6  =  RN4T6  +  SELECTED . WIDTH  /  43.2 
else  if  MEANS  =  ''H-RAFT"  then 
case  WIDTH  <=  100 

RM4T6  =  RM4T6  +0.5 
case  ICO  <  WIDTH  <=  200 

RM4T6  =  RM4T6  +1.0 
case  200  <  WIDTH  <=  300 

RM4T6  =  RM4T6  +1.5 
case  300  <  WIDTH 

RN4T6  =  RM4T6  *  2.0 
else  (*  MEANS  =  L . RAFT  *) 
case  WIDTH  <=  100 

RLTR  =  RLTR  +  1 
case  100  <  WIDTH  <=  200 

3T  ~R  =  R*  "rR  4-  "> 

case  2C0 *<  WIDTH‘<=  300 
RLTR  =  RLTR  +  3 
case  300  <  WIDTH 

RLTR  =  RLTR  +  4 

endif 
er.dif 
end  while 

***  Estimate  Possibility  *** 
if  MAFE  <  RAF 3  or  MLTR  <  RLTR  or  MM4T6  <  RM4T6  then 
"Meed  support  frem  other  engineer  unit" 
else  'River  Crossing  Operation  is  possible" 
s  r*  c  z.  r 

Survey  Supporting  Unit  Module 

***  search  MUNIT  from  ASSIGN  *** 
if  found  then  HIGHER  =  ASSIGN. BELONG 
select  UNIT 
from  ASSIGN 

where  ASSIGN. BELONG  =  HIGHER 
insert.  to  TEN? 
while  net  e off  TEMP) 
select  UNIT 
from  ASSIGN 
where  I 'AN? .  UNI .  = 

insert  to  SUPPORT 


ASSIGN. BELONG 


end  wnne 

select  UNIT,  AFB,  LTR ,  M4T6 
from  UNITEQP 
vhere  SUPPORT . UNIT  =  UNITED 
else  '  There  does  not  exist  M’JNIr1 
e.ndif 

Generate  Crossing  Capacity  Module 


HV 

KRA 

HV 

3RG 

"  *7 

LTR 

V  V 

KRA 

m; 

SRG 

H. 

T 

OTA 

Number  of  heavy  vehicle  that  can  be  crossed  by  h.raft 

.‘lumber  of  heavy  vehicle  that  can  be  crossed  by  bridge 

Humber  of  light  vehicle  that  can  be  crossed  by  LTR 

Number  of  light  vehicle  that  can  be  crossed  by  h.raft 

Nu.T.ber  of  light  vehicle  that  can  be  crossed  by  bridae 

Total  number ‘of  heavy  vehicle  that  are  already  crossed 

Total  number  of  light  vehicle  that  are  already  crossed 

Heavy  raft  assemble  time 

Bridge  assemble  time 

LTR  assemble  time 

Hours  to  cross  light  vehicle 

Hours  to  cross  heavy  vehicle 

L . HOUR  =  0,  LV.LTR  =  0, 

0,  HV.BRGE  =  0,  H. TOTAL  =  0 
0,  LV.BRGE  =  0,  L. TOTAL  =  0 


L. TOTAL  ;  Total  number  of  light  vehicle  that  are  alrec 

AT. KRAFT  :  Heavy  raft  assemble  time 

AT.BRGE  :  Bridge  assemble  time 

AT. LTR  :  LTR  assemble  time 

L.HOl'R  :  Hours  to  cross  light  vehicle 

HOUR  :  Hours  to  cross  heavy  vehicle 

HOUR  =  0,  L . HOUR  =  0,  LV.LTR  =  0, 

KV.HRAFT  =  0,  HV.BRGE  =  0,  H. TOTAL  =  0 
LV.HRAFT  =  0,  LV.BRGE  =  0,  L. TOTAL  =  0 

while  HOUR  <=  AT.HRAFT  or  HOUR  <  AT.BRGE 
if  HOUR  >  AT.HRAFT  then 

HV.HRAFT  =  HV . KRAFT  +  (TRIPS  *  NUM. H.RAFT  ) 

H.  TOTAL  =  H. TOTAL  +  HV.HRAFT 
HOUR  =  HOUR  +  1 
endif 
end  while 

while  H. TOTAL  <  H.VEH  do 

HV.HRAFT  =  HV.HRAFT  +  (  TRIPS  *  NUM.HRAFT  ) 

HV.BRGE  =  HV.BRGE  +  (  200  *  NUM.SRGE  ) 

H.  TOTAL  =  H. TOTAL  +  HV.HRAFT  +  HV.BRGE 
HOUR  =  HOUR  +  1 

end  while 

while  AT. LTR  >=  L.HOUR  do 

I.  TOTAL  =  LV.LTR 
L.HOUR  =  L.HOUR  +  1 

end  while 

while  L. TOTAL  <  L.VEH  do 

LV.LTR  =  LV.LTR  +  (  TRIPS  *  NUM. LTR  ) 

“lv\RHRAFT  *= 'LV.HRAFT  +  (  TRIPS  *  NUM.HRAFT  *  2  ) 
LV.BRGE  =  LV.BRGE  +  (  200  *  NUK.6RGE  ) 
endif 

L. TOTAL  =  L. TOTAL  +  LV.LTR  *  LV.HRAFT  +  LV.BRGE 
L.HOUR  =  L.HC'JR  +  1 
er.c  while 

if  L.HOUR  >=  Hour  then  FINISHING  TIME  =  L.HOUR 
else  FINISHING  TIME  =  HOUR 


•V 


obstacle/denial  operation  subsystem 

a.  Get  Data  Module 


Input  Data 

MRNUH  :  Road  number 

FROM  :  Coordinate  of  starting  point  of  road  segmen 
ENDED  :  Coordinate  cf  ending  point  of  road  segment 
RDTIME  :  Required  delay  time 

Examine  Necessitv  Module 


Search  planned  targets  in  this  segment  of  road  *** 
J oir.  with  r.D_OSJ  and  TARGETS  to  TEM? 


for  MRNUM  =  RD_OE J . RNUM ,  RD_C3J.0TYPE  =  'OBST1 
RD_C3 J . LOO  =  TARGETS. LOC 


select  TNUM ,  LOC,  TTYPE,  DTIME  STATE 
from  TEMP 

where  LOCI  <=  TEMP. LOC  <=  L0C2 
insert  to  TEMPI 

Calculate  Delay  Time  *** 

SUM  =  0 

while  not  eof (TEMPI) 

if  TEMPI. STATE  =  'done1  then 

SUM  =  SUM  +  TEMPI. DTIME  endif 
end  while 


***  Estimate  Necessity  *** 

it  SUM  N=  RTIHE  then  "Don't  need  Additional  Operation" 
ease  ADDTIME  =  RTIME  -  S'JM,  "Need  Additional  Operation' 

Select  Targets  Module 
Incut  Option 

Target  Type  :  Taraet  that  vou  want  to  be  denied 
Selecting  Criteria  :  MAM.  and  MIN.  number  of  targets 

Select  Proper  Target 

sort  TEMPI  with  Delay  Time ( ascending  order) 
if  TYPE  =  'ALL'  then 

if  CRITERIA  =  MAX  then  ao  to  the  end  of  TEMPI 
while  SUM  <  ADDTIME  cr  not  bof ( TEMP ) 
select  TNUM ,  LCC,  TYPE,  DTIME 
from  TEMPI 
where  STATE  =  'plan' 

SUM  =  SUM  r  DTIME 
end  while 

else  CRITERIA  =  MIN  *) 

while  SUM  <  ADDTIME  or  net  eof (TEMPI) 
select  TNUM,  LCC,  TYPE,  DTIME 
from  TEMPI 
where  STA.E  =  'olan' 

SUM  =  SUM  t  DTIME 
end  while 


while  MORE  -  true 

if  CRITERIA  =  MAX  then  goto  bottom 


w.-.ile  SUM  <  AD: 


net  do t 


select  TNUM,  LOC,  TYPE,  DTIME 
from  TEMPI 

where  STATE  =  olan',  TYPE  =  Input  target 
SUM  =  SUM  *  DTIME 
end  while 

else  (  CRITERIA  =  MIN  *) 

while  SUM  •  ADDTIME  cr  not  eofi'TEMPl) 
select  TNUM,  LCC  TYPE,  DTIME 
from  TEMPI 

where  STATE  =  clan1 ,  TYPE  =  Input  taraet 

C’>f  —  -•>>•  ' 

S'-.'*  -  Sui’l  + 


?nc  wn ia.e 


'Need  other  type  cf  tar 


'.-•i’A.u'j -'j 


’■..‘v'.l-V'j  V 


a  -  .y. 


V'.V.v  YaaT-V.V  .v .  j-.’-r.V. 


MORE  =  true 
else  MCP.E  =  folse 
endif 
end  while 
endif 

if  SUM  <  ADDTIME  then  "Impossible  within  this  segment" 
call  EXTEND  SEGMENT 
else  DISPLAY  OUTPUT 
endif 

Extend  Segment  Module 

Determine  the  Direction  of  Road 
AX  =  abs  [  X . LOCI  -  X.LOC2  ) 

AY  =  abs  (  Y . LOCI  -  Y.L0C2  ) 

if  AX  >  AY  then  "Direction  of  road  :  East  to  West" 
else  "Direction  of  road  ;  South  to  North"  endif 

***  Search  Targets  *** 
if  AX  ■  AY  then 

if  X . LOCI  >  X.L0C2  then 

while  SUM  <  ADDTIME  or  bof (TEMP ) 

select  TNUM ,  LOG,  TYPE,  DTIME,  STATE 
from  INDEXED  TEMP 
where  X.LOC  <  X.LCC2 
SUM  =  SUM  +  DTIME 
end  while 
else 

while  SUM  <  AD DTI ME  or  eof (TEMP) 

select  TNUM,  LOC,  TYPE,  DTIME,  STATE 
from  INDEXED  TEMP 
where  X.LOC  >  X.L0C2 
SUM  =  SUM  +  DTIME 
end  while 
endif 

else  if  Y’ .LOCI  >  Y  LCC2  then 

while  SUM  <  ADDTIME  or  bof (TEMP) 

select  TNUM,  LOC,  TYPE,  DTIME,  STATE 
from  INDEXED  TEMP 
••here  Y.LOC  <  Y.L0C2 
SUM  =  SUM  +  DTIME 
*nd  while 

else  while  SUM  <  ADDTIME  or  eof ( TEMP ) 

select  TNUM,  LOC,  TYPE,  DTIME,  STATE 
from  INDEXED  TEMP 
where  Y.LOC  >  Y.L0C2 
SUM  =  SUM  +  DTIME 
end  while 

endif 


endif 


APPENDIX  B 

PROGRAM  LISTING  OF  THE  RIVER  CROSSING  OPERATION 


.  Main  Program 


.vst.ncr 


ENGINEER  .  PRO 

71  Module  name  :  ENGINEER. PRG 

Jang,  Chang  Ki 

This  is  a  engineer  Operation  System  to  support  ; 
the  dec  is  ion ‘making  'during  the  Army  Engineer  Oc-  * 
e ration.  This  module  calls  the  submodules  of  this' 
system  to  execute  the  v:hcie  system.  * 

Svstem  start  up  ( dBASE  III  Plus)  ' 

NeNUSCR,  RIVER,  DENIAL,  FMODIFY  * 


;rpose 


*  Called  by 
75  Calls 

*  Variables 

'  Global 


Local 


OPTION  :  Holds  the  user’s  input  option 
TODAY  :  Date  of  todav 


none 


-  Close  all  open  files 

-  Set  working  environment 


Lear  aij 


set  talk  off 
set  heading  off 
set  safety  off 
set  status  off 


public  TODAY,  OPTION 
store  scace(l)  to  OPTION 
store  cataf )  to  TODAY 


Define  public  variable 


•-  This  sets  up  the  CRASH . TXT  file  which  records  all  actions  so 
■-  that  if  the  system  crashes  the  data  base  can  be  recreated. 
This  files  is  deleted  if  the  system  terminates  normally. 


3  e  _ 


aits  to  crasn 
alte  or. 

/nils  .T. 

- -  Clear  the  screen  and  display  the  main  menu 

clear 

do  KENTS CR 
set  color  to  R* 

5  1,15  say  ARMY  ENGINEER  OPERATION" 

-  5,22  sav  "M  E  N  U’ 

Plv.23  say  "INFORMATION" 
set  color  to  G 

2,22  sav  "F.  :  RIVER  CROSSING  OPERATION" 

DENIAL  (OBSTACLE)  OPERATION" 

DATA  FILE  MODIFY  ' 


emit  from  running" 


hi  1 , 22  say  "D 
22  say  M  : 
color*  to  ?.+ 

22  cay  "M  ; 
color* to  W 
22, say  time() 
o c  * o to  A* 

12  Enter  selection  (  R,  D,  M,  or  X  to  Exit  )  : 


.  say  1  get  OFTION 
unnerf OPTION)  tc  OFTION 


case  OPTION  =  'X' 
clear  all 
auit 

case  OP'TICN  =  'R' 
do  RIVER 
exit 

case  OPTION  =  1 D  ' 
do  DENIAL 
exit 

case  OPTION  =  ' M* 
do  -MODIFY 
exit 

*• - Error  condition  of  user's  option 

otherwise 

120,  3  say  space(18) 

020,60  say  space;  5' 

021,  5  say  space (62) 
set  color  to  R+ 

021 ,2C  say  "ERROR  MESSAGE - ILLEGAL  OPTION  :"+OPTICN 

set  color  to  W 
??  chr(7) 

023,61  say  ""  get  OPTION 
023,62  say  space(l) 
read 

store  upper (OPTION)  to  OPTION 
endcase 

-  End  0f  loop 


enddo 

set  alte  off 
clear  all 
close  alte 
erase  CRASH. TXI 


End  of  main  loop 


END  OF  MAIN  PROGRAM 


k-k7c-k-k-k-k-k'k-k-k-k-k-k'k7'-k'k’k-k'k+rk-k'k'k-k-k-k-k-k-k-k-k4<+;'k-k-k-k7tT;'k-k-k 

M  E  N  U  S  C  R  .  F  R  G  **** 


Le  name  :  MENUS CR . PRG  * 

;se  :  This  is  a  HENUSCR  module  of  Engineer  Operation  * 

svstem  to  format  the  screen.  * 

?d  bv  :  EflGINEER  * 


date (  ) 
to  3,69 
to  24,77  double 
to  17,75 
to  7,4  double 
s ay  spate < 15 ) 
to  22, '5 
to  20,46 
say  space(15) 

say  replicate (chr( 176 ), 25 ) 

say  chr  .  176 

say  chr! 176 i 

say  chr; 176) 

say  cr.r;17i,> 

say  chr (176) 

s  a  y  o  h  r ;  1 7  6  ) 

say  chr; 1^6) 

s  a  v  c  a.  r .  1 1  6 ) 

sty  chr ( 175 ) 

s  a v  chr  176; 


0 

1 9  2 

sav 

chri 176) 

£ 

-i  -» 

L.  v-  ,  <_ 

SaV 

chr :I’5i 

fi 

vi  —  . 

s  av 

chr  *  1  “* 6  j 

0 

O 

_  —  .  L. 

s  a  v 

c  h  r  1 7  6  ) 

i:  ? 

s  ay 

reclicate  ch 

V? 

7  - 

sav 

cr.V  ■  i 7  6  ) 

2T  3 

s  av* 

chr  v 17  3 ) 

-  “*  N 

s  av 

chr; 176 ; 

a 

19.7c 

S  3  V 

chr v 175 

IS  4"1 

s  av 

: eolicace ; ch 

iji 

-  7  .,  .  c 

3  a  y 

chrv:7d; 

1  C  ,  :  C 

s  ay 

c r,  r  \  1  ••  o  j 

C! 

15,^5 

s  av 

c  n  r  •  j.  7  6  ) 

a 

14.76 

S  5.  V 

c  h  r  ;  1 7  3  ) 

a 

*  *  ~  H 

s  av 

chr  ( 176 i 

i  2  7  n 

5  av 

chrt 176 ; 

3 

,  -»  _ 

a  a  v 

c  h  r  ;  1 7  6 ) 

2 

*  (-\  ->  ^ 

S  a.  V 

chr \ 176) 

C  7  A 

say 

chr v 176) 

5  76 

sav 

chr [116) 

Z 

,  /  c 

sav 

chr { 176 ) 

a 

6  To 

say 

chr; 176) 

■3 

5 , 4  ? 

sav 

reoiicate ( ch 

c 

19,33 

sav 

INFORMATION 

3 

20 , 14 

sav 

1  DATE  1 

'  ct 

2  3,61 

sav 

"TIME11 

Cl 

*1 1  ,  1 2 

sav 

tcdav 

.3 

21,53 

sav 

time; ) 

*■  Q 

turn 

END  OF  MENUS CR 


2.  River  Crossing  Operation  Subsystem 


R  I  V  E  R  .  P  R  G 


*  Module  name 

*  Purpose 


T  Called  by 
71  Calls 

x 

*  Variables 

*  Global 


~  _ocai 


RIVER . PRG  * 
This  is  a  River  Crossing  Operation  Support  Sys-  * 
tern,  this  svstem  controls  the  overall  subsystem  " 
of  this  svstem.  * 
ENGINEER  *  * 
MENUS CR ,  GETDATA ,  NECESSRC,  POSSIBLE,  SUPPORT  * 
GENERATE  * 

XT 

M’JNIT,  MRNAME ,  LEFT,  RIGHT,  MIDDLE,  AJBRG,  * 
3_BRG ,  A_RAFT ,  B_RAFT ,  MAFB ,  MLTR ,  MM4T6 ,  * 
RAFS,  RLTR ,  RM4T6  * 
TODAY  :  Date  of  today  * 
none  .  * 


Clear  all  open  file 


1  3  *  Jv  Ci 

-.lie  .1 


lDOLc 

ERG, 
"RAFT , 
-.FB,ML 
-.PE  ,  RL 
:  CIS  10! 
JMIT, 


-  Define  the  global  variables 

:  Name  of  the  river  crossing  command 
:  Name  of  the  river  to  cross 
:  Coordinate  of  left  boundary  of  area 
:  Coordinate  of  right  boundary  of  area 
:  Coordinate  of  center  of  crossing  area 
B_BRG  :  Number  of  bridge  sites  in  area  A  and  B 

3_RAFT  :  Number  of  raft  sites  in  area  A  and  5 

TR , MK4T6  :  Available  amount  of  equipments 

TR , RM4T6  :  Required  amount  of  equipments 

N  :  Users  decision 

MRNAME,  LEFT,  RIGHT,  MIDDLE,  DECISION,  OPTION,; 


V-4  l«  V-t  V4  V-*  w  ,1 

o  o  OOOO 

o 

</)  in  '/)  <n  V)  V)  rO 


A_BRG ,  B  3RG ,  A_RAFT ,  3_RAFT ,  MAFB ,  MLTR,  MM4T6,  RAFB, ; 
RLIS ,  RM4T6 

store  space (6)  to  MUMIT 
a  space (10)  to  MRNAME 
e  soace(S)  to  LEFT 
a  sbace(S)  to  RIGHT 
e  space(,l)  to  OPTION,  DECISION 
e  0  to  A  BRG,  S_BRG ,  A_RAFT ,  B_RAFT 
a  0  to  MAFB ,  MLTR,  MM4T6 ,  RAFB,  RLTR,  RM4T6 
h  ’  ^  6  .  T  . 

-  . . Call  GETDATA  to  define  operational  environment 

do  GETDATA 
if  OPTION  =  'X' 
clear  all 

return  r  rvri>vrrn 

_ _ Return  to  mam  menu  of  Er.G-.NEER 

. . Call  NECESSRS  to  estimate  necessity 

do  NECESSRC 
if  OPTION  =  'X' 
clear  all 

. - . Back  to  the  RIVER 

l-.-f . . Call  POSSIBLE  to  estimate  possibility 

do  POSSIBLE 
if  OPTION  =  'Y1 
do  SUPPORT 
endif 

if  OPTION  =  'X' 
clear  all 
exit 


e  n  01  z 


OPTION  =  'X' 
clear  all 
exit 


-3  J  - 


e  r.  t  z.  0 


return 


-  Back  to  the  RIVER 

Call  GENERATE  to  estimate  finishing  time 


Back  to  the  RIVER 
-  end  of  Iood 


END  OF  RIVER. PRG 


Sat  Tata 


^  V  »  -  X  ■*  * 


-  —  GETDATA  .  PRG  .  .  ,  .  **** 

•  M;  d'.; _ a  name  :  SETDATA .  PRG  . 

-  e-  r-s»  •  This  is  a  GETDATA  module  to  define  operational 

-  environments  such  as  name  of  river  crossing  co¬ 
mmand,  name  of  river,  and  river  crossing  area.  ’ 
c:vf= 


DV 


i  z.  r. 


a  _ 


Call  MENUS CR  to  formating  the  screen 


ROSS 


G  OPERATION 


3  9,21  sav  "RIVER  CROSSING  COMMAND  :  11 

=  11,21  say  "NAME  OF  RIVER  TO  CROSS  :  11 

3  13,21  say  "CO-ORDINATES  OF  RIVER  CROSSING  AREA" 

3  15,13  say  "LEFT" 

3  13.31  sav  "MIDDLE" 

3  13,50  say  "RIGHT" 

set  color  to  W 
3  21,33  say  time() 
set  color  to  R-r 

3  23,13  say  "  Press  anv  key  tc  RUM  or  Press  'a'  to  EXIT  : 

3  23,52  say  ""  get  OPTION 

read 

set  color  to  W 

store  uooer (OPTION)  to  OPTION 
if  OPTION  =  ■ 


,  -  Back  to  main  menu  of  ENGINEER 

do ile  .T. 

■3  9,43  say  ""  get  HUN  IT 

re  ad 

store  uooer  (M’JNIT )  to  MUNIT 
3  11 ,43'  say  11  1  get  MRNAME 
re  ad 

store  upper (MRNAME)  to  MRNAME 
3  15,20* say  ""  get  LEFT 
read 

store  UDper(LEFT^  to  LEFT 
■3  15,39*  say  ""  get  MIDDLE 
V  -  au 

store  uoper (MIDDLE)  to  MIDDLE 
3  15, 57' say  ""  get  RIGHT 
read 

store  upper (RIGHT)  to  RIGHT 
set  color  to  ?+ 

<3  16,15  sav  "Press  'C1  change  data  or  Press  any  key  :  " 
set  color  to  V? 

3  16,62  say  11  get  OPTION 


store  uooer (OPTION)  to  OPTION 
if  OPT  I  Oil  <>  'C' 
exit 
ended 
er.ddo 

3  23,62  say  ""  get  OPTION 
re  ad 

store  upoer (OPTION)  to  OPTION 

if  optic!;  =  ‘X: 

return 

- -  Back  to  main  menu  of  ENGINEER 

else 

exit 

a  v-  J  ■.  -0 
0 

rn 

===============  END  OF  GET  DATA  .  PRG  =====—==========* 


4 .  He 


sitv  Module 


*^x;»xxxxxx:*:xxxxxxxxxxxx  +  x*£x^xx:*x*;kxxxxx.xxxxxxXxxxxxxxx*xxxx-i--»-xxxx 

****  wecessrc.prg 

^mcxxxxxxxx^:Vxxxxx:<xxxxxxxxx.xxxx:txxxxxxxxxxxx*xxxxxxxxx*xxxxxxxxx:'>x 


X 

Module  name 

:  KECESSRC . FRG 

X 

X 

Pure  s s a 

:  This  is  a  NECESSRC  module  to  estimate  the  nece- 

X 

x 

ssitv  of  river  crossing  ooeraticn. 

X 

X 

Called  by 

:  RIVE?. 

X 

Calls 

:  EXI3TERG,  CALCSITE 

X 

Variables 

X 

Local 

:  AREA,  LOCI.  LCC2 ,  ANEED,  BLEED,  MX,  ML I ME , 

X 

X 

BRGESITE ,  RAFTSITE  . 

K 

XX^XXXXXXXXXXXXXX'XXXXXrX^XXXX^XXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXXXXX 


AREA 


set  talk  off 
c  1 e  a  r 

* - Define  the  local  variables 

nfea  of  river  crossing  operation 
Coordinates  of  river  crossing  area 
Necessity  of  operation  for  area  A  and  B 
Retrained* number  of  bridge  sites 
Required  number  of  raft  sites 
line  control  variable  for  output 
Pointer  variable  for  data  base  files 


- .-.NEED,  SNEED 

*  . 3RGESITE 

- - RAFTSITE 

v _ :  v  t  Mr 

*  _ MV 

store  space (1)  to  AREA 
store  scace.S)  to  11C1 
store  1  to  A_BRGZ ,  S_BRGE , MX 
store  3  to  A_RAFT  B_RAFT 
store  .1.  to  AMEED .  SNEED 
store  C  to  3RD-ESI7E,  RAFTSITE 
store  A1  to  AREA 
store  7  to  KLINE 


LOG  2 


1ZFT  t o  LOCI 

IIdSleGo'ToCZ 


Define  the  working  area 


use  ?.I V  OBJ  index  RIV  OBJ 


se  BRIDGES  index  BRIDGES 

- - TEMP  contains  the  all  bridges  in  this  river 

ein  vi th  RI7_CBJ  to  TEM?  for  B->  LGC  =  A->  LOC  .and.; 

KRIIAKS  fields  ICC,  BMAME ,  CLASS,  STATE 


k-s  PLANE 
tony  structure  to  TEMPI 
do‘ while  . T. 


EXISTSRG  WITH  A 

-  I  C  ‘ 


-  Cali  existing  bridge  module  EXISTBRG 

AREA ,  AMEED,  5  ME  ZD  ,  MlxME  ,  MX 


exit 

endif 
A? =  ’ 3 1 

I::2  =  RIGHT*" 

y  A  A~. 


DRIES ITE  =  A_BRG 
RAFTSITE  =  A_EAF 


+  B_BRG 
*  B_RAFT 

and.  RAFTSITE  =  6 
6,12  to  S , 62 
color  to  Rt 

7 . . 7  "THERE  IS  MO  AVAILABLE  BRIDGE  IN  THIS  AREA1 


er.oi: 

if  .r.ot.  AM'EED )  .and.  .not.  (BLEED) 

5  17,11  to  20,60  double 
set  color  to  R~ 

■"5  1  - s  «v  "RIVER  CROSSING  OPERATION 


IS  NOT  NECESSARY 


set  cclcr  to  R+ 

3  14,20  say  "REQUIRED  NUMBER  OF  CROSSING  SITES' 
set  color  to  W 


£ 

16.16 

say 

"SITE" 

16,31 

say 

II  »  M 

a 

16.42 

say 

"3" 

?. 

16,53 

say 

"TOTAL" 

r. 

'  1  .2 

say 

replicate ( "=" ,  4) 

r 

1  ^  33 

say 

replicate ("=“ ,  3) 

-c 

l-?  ,41 

s  a  y 

replicate ; "=" ,  3 ) 

1^,53 

c-  3  •_* 

reblicate ( "=" ,  5) 

•3 

19*6 

say 

"RAFT" 

3 

1 9^21 

say 

1 1  r  im.  ( s  t  r  ( A_RAFT ) ) 

3 

19.42 

say 

Itriml str ( B_RArT ) ) 

3 

19.55 

say- 

ltrimtstr'.RAFTSITE ) ) 

3 

-  ,  1 0 

say 

ERIDGE" 

is* 

21.21 

sav 

Itrimt str (A  ERG)) 

21,42 

say- 

Itri.T.i  str  (  3_ERG) ) 

fa 

21,55 

say 

I trim  '  s tr (3RGESITE ) ) 

elcr  t 
14  sav 

c  R4- 
"?,- 

ess  anv  kev  to  ccntin 

2  , 

64  say 

"  ,■ 

get  CrtlClf 

'X"  to  EXIT 


set  color  to  V 

store  upper; OPTION)  to  OPTION 
return 

END  OF 


NECESSRC.PRG 


—  ~  —  —  —  —  —  —  —  =  —  —  — 


E  X  I  S  T  B  R  G  .  P  R  G 

Module  name  :  EXISTERG . PRG  * 

:  This  is  a  sub-module  of  NECESSRC  to  examine  the  * 
existing  available  bridges  in  this  area.  * 

•  NECESSRC 


.-urccse 


Called  by 
■enables 


:w_,g^ai.^O,^P,  .V,  ,W,  J, 


parameters  .-.REA ,  LOCI,  LCC2 

- - • —  Define  the  local  variables  to  represent  location 


va 


•-■  3 


ub  s  t  r 

( LCCl , 

3 , 3 

ub  str 

\LZZ2  , 

3,3 

ub  s  t  r 

[r  C<~  1 

6 , 3 

ub  str 

{ L0C2 , 

0 ,  3 

uir  s  *1? 

[  3.  z.  r  ± 

3,3 

1  —.2  3  V 

<  RIGHT 

,3, 

:  ub  s  t r 

,  LEFT  , 

6 , 3 

1  u*-3  S  v- 1 

..RIGHT 

,  D  , . 

"  -  z 

> 

Define  the  working  area 


se  -  e 


Searching  the  available  existing  bridgs 
TEMPI  contains  the  available  bridges 


:re  upper subs tr  <  LCC  .  1 , 2 ) )  to  ? 
'  ‘  aubstr 1 LCC , 3 .  2 ;  < 


■  a  _  z>  . 

va.  subs  tr '.  IOC  ,6 . 3) ; 
:  a  3  e 

case  AM  <  AT 

:i  •  =  1  . ar.d. 


(-U 


-■*  -  ‘ 


STATE 


.  ar.d .  ; 


( ( T  <=  U  .and.  U  <=  V)  .or.  (V  <=  U  .and.  U  <=  T)) 
select  TEMPI 
aopend  blank 

replace  LOG  with  TEMP->LOC,  BMAME  with  TEMP -> BMAME , 
CLASS  with  TWMF- > CLASS ,  STATE  with  TEMP- > STATE 

endif 

case  AX  =  AY 

if  ?  =  0  .and.  STATE  =  'AVAIL'  .and.; 

((T  <=  U  .and.  TJ  <  =  V)  .or.  (V  <=  U  .and.  U  <=  T)) 
select  TEMPI 
aopend  blank 

reolace  LOC  with  TEMP->LCC,  BMAME  with  TEMP->3NAME , ; 
CLASS  with  TV;MP-> CLASS ,  STATE  with  TEMP-ESTATE 

else 

if  P  =  0  .and.  STATE  =  'AVAIL'  .and.; 

((Q  <=  R  .ar.d.  R  <=  S)  .or.  (S  <=  R  .ana.  R  <=  Q)) 
select  TEMPI 
append  blank 

replace  LOC  with  TEMP->LCC,  EMAME  with  TEMP -> BMAME , ; 
CLASS  with  TWM?-> CLASS ,  STATE  with  TEMP- ESTATE 

endif 

endif 

case  AX  >  AY 

if  P  =  0  .and.  STATE  =  'AVAIL'  .and.; 

t  (0  <=  R  .ar.d.  R  <=  S;  .or.  (5  <=  R  .and.  R  <=  0;) 
select  TEMPI 
aopend  blank 

reolace  LOC  with  TEMP-ELOC,  BMAME  with  TEMP->3WAME , • 
CLASS  with  TWMP-> CLASS,  STATE  with  TEMP -ESTATE 

endif 

endcase 
select  TEMP 

S  rl  ip 

enddo 
clcse  all 
r  6  z  u  r  n 

-=================  EMD  OF  EXISTBRG . PRG  ================* 


;se 


CALCS  ITE.  PRG  + 

:  CALCS ITE . PRG  * 

:  This  is  a  sub-module  of  MECESSRC  to  calculate  the"' 

required  number  of  crossing  sites.  * 

mt  -*r ccor  -r 


parameters  AREA,  AMEED,  BNEED ,  KLINE ,  MX 
set  talk  off 
use  TEMPI 

if  ML!!. 'I  =  7  .and.  reccount()  >  0 
0  1,24  to  3,50 

set  color  to  Re¬ 


3 

2 ,  25 

3  3  V 

"AVAILABLE 

BIDGES 

5  *5 

t  coior  to 

W 

3 

4,16 

say 

"AREA" 

3 

4,25 

say 

'LOCATION" 

3 

4,33 

say 

"BRIDGE  NAME" 

4,54 

say 

"CLASS" 

i  i 

-  .  4.  J 

say 

replicate  < "  =  " 

-  \) 

'i 

2  ,  2.2 

say 

replicate  (  " 

/  3  •’ 

z 

2  i  5 

say 

replicate ( "=" 

,11) 

3 

3  .  34 

say 

replicate •  '=" 

,  5  ) 

late  MX 


reoccur. t  ( ) 


it  mrorom 


.IS  say  AREA 
,25  say  LOCA 
,40  say  ENAME 
,56  say  CLASS 
ML IKE*  +  1 
is  A.a£,A  —  1  ■  A " 
it  A  BRG  -  0 

it  A_RAFT  =  0 

a  need  =  .f. 

if  CLASS  >=  20 
A_RAFI  =  A 
else 

A_RAFT  =  A 
er.dif" 
endif 
else 

if  CLASS  >=  45 
A_BRG  -  0 
e  Ise 

if  CLASS  >=  20 
A_RAFT  =  A 
else 

A  RAFT  =  A. 
er.di  r 
endif 
endif 

else 

if  E  BRG  =  0 

if  3_RAFT  =  0 
SNEED  =  .F. 
else 

if  CLASS  >=  20 
E_RAFT  =  3_ 
else 

3  RAFT  =  B_ 
endif" 
endif 
else 

if  CLASS  >=  45 
3_ERG  =  C 
else 

if  CLASS  >=  20 
3_RAFT  =  3_ 

A  '  £  e 

'e^RAFT  =  B_ 
^  n  d '  ^ ~ 
endif 
endif 
•  ndif 

-  i 


RAFT  -  2 
RAFT  -  1 


RAFT  -  2 
RAFT  -  1 


RAFT  -  2 
RAFT  -  1 


RAFT  -  2 
RAFT  -  1 


n 


END  OF  CALCEFQS  .FR: 


POSSIBLE  .PRG  . 

r  ■■■  t  x  •*  TK^t*’t7r^xxK'*rtxxr^'»:^x5'rtirK,nxtw?;K  *  +■  ? 


■"  Module  name  :  POSSIBLE. PRG 

"  Purcose  :  This  is  a  POSSIBLE  module  to  estimate  the  poss- 

"  '  utility  of  river  crossing  operation  with  organ¬ 

ized  engineer  units  and  their  equipments. 
x  Tailed  bv  :  RIVER 

*  Calls  '  :  SELSITE,  L'NITEOPS,  CALCEQPS 

*  Variables 

Local  :  MCREAF5,  MORELTR ,  H0REM4T6 

-<rir'r-*--*-«rXXXXXXXXXXXXX«<:XX.TXX;i'r  «rX  TXXXXX-'-XXXXXXXXXX^XXXXXXXXXXXXX*’:';*':*-? 


- - - Define  the  local  variables 

r - MCRtAr B  :  Lack  of  r*FB 

r . . KCRZL7R  :  Lack  of  LTR 

- - MOREM'iTo  :  Lack  of  M4T3 

* - MEED  :  Boolean  variable 

store  l.C  to  M0REAF3 ,  MORELTR ,  M0REH476 
store  . F .  to  MEED 

T -  Calls  SELSITE  to  select  the  river  crossing  sites 


Return  to  RIVER. PRG 


' -  Calls  L'NITEJPS  to  examine  the  organized  engineer 

■ -  units  and  their  river  crossing  equipments. 


Return  to  RIVER. PRG 


Tails  C.-.LCECP5  to  calculate  the  required  equipments 


Return  to  RIVER. PRG 


MCREAF3  -  RAFB  -  .VAFB 
endi  f 

if  RLTR  >  MLTR 


:R  =  RLTR  -  MLTR 


if  RN476  >  MM4TS 
MEED  =  .T. 

; ; . REM4TS  =  RM4TS  -  MM4T6 


EE  to  4,54 

ZP  sav  ! STATUE  CF  EQ 

32  say  AF3" 

44  say  "LTR  1 
31  say  "M4T6-1 

31  say  replicate < "=  1 ,  5) 
4  3  sey  replicate  '=  ; ,  z  > 

33  sav  reclicate ' "=" ,  4; 
14  sav  AVAILABLE' 

32  sav  sir- UAF3 ,3,1' 

44  say  s t r ( MLTR .3,1; 

* .  s  a  *  s  ■- i  i . ..'.4 * o  ,e  .  .  J 


F  EQUIPMENTS' 


sav  str  F 5  ,  o  ,  .. 


vV  UV  Vw" ./k'O^LZlVvkLvLu  Ui'Ua.  n  “0.  U*  L.vtfW  A  -*»  -U  _*«. .  '■Lu  ,Im  2kB  Jm 


'  fD  t*  oi  o)(q){u>(q) 


10. 44  say  str(RLTR, 3,1) 

10,36  say  str (RM4T6 , 3 , 1 ) 

14,15  say  "LACK' 

14,32  sav  str (MOREAFB , 3 , 1 ) 

14.44  say  str (MGRELTR .3,1  ) 

14,56  say  str (M0RzH4T6 , 3 , 1 ) 

et  color  to  R+ 
f  NEED 

?  13,17  say  "NEED  ADDITIONAL  EQUIPMENT  TO  SUCCESS  !!" 

$  21,14  say  "Do  you  want  to  search  supportma  unit?  (Y/N) 

2  21 ,63  sav  oet  OPTION 
read 

store  upper; OPTION )  to  OPTION 

. Return  to  RIVER. PRG 

end  if 
Ise 

3  It,  15  say  "WE  HAVE  ENOUGH  E QUIFMENTS  TO  CONDUCT  OPERATIC 
**>  ^  £ 

23,14  say  "Press  any  key  to  continue  or  Press  "X"  to  EXIT  : 
et  color  to  R-r 
23,64  get  OPTION 

1  a  3N 

stare  uooerl OPTION)  to  OPTION 


END  OF  POSSIBLE. PRG 


me  :  Sidl.E.rr.J 

:  This  is  a  sub-module  of  POSSIBLE  to  select  the 
rit'er  crossing  sites  in  each  area  A  and  B. 
t  :  PCSSI3LE 

:  INAREA ,  CHOOSING 

I'.  ■*■*■*■*;  •*■*  ■*  X 


lure  to  TEMP 
ture  to  TEHP_A 
sure  to  TEMP  3 
sure  to  TENP'C 
J 

-  TEMPI  contains  the  all  crossing  sites  in  this  river 

■!?1  for  OTYFE  =  'SITE  .and.  RNANE  =  MRNAKE 


1C  to  TEMPI 


Define  the  working  area 


index  TEMPI 


IE  index  CORSSITo 
on  to  LOC  into  mMPl 

.  Jem  with  TEMPI  and  CROSSITE  to  TEMP 

-  TEMP  contains  the  characteristics  of  all 

-  river  crossing  sites  in  this  river. 

net .  eof ! ) 
tero  1 
: .  e  b  f  (  ') 
ect  TEN? 
end  blank 

lace  LOC  with  TEMPl-'LCC,  width  with  CROSSITE- -WIDTH  , 
DEP.H  with  IPCSSITE-  •Dc.P.H.  7EL0  with  CROSSITE-  'VELO,  : 
CBSTAC  WITH  C.e^-SS  ITE-  ’IBS. AC 


m 


select  CR0S5ITE 
skip 
enddo 
close  all 

^ -  Calls  INAREA  to  search  the  crossing  sites 

- -  in  the  river  crossing  area. 

do  INAREA 
c  3,21  tc  5,55 
set  color  to  R+ 

3  4,25  say  "SELECTED  CROSSING  SITES" 

set  color  to  W 
3  7.13  say  "AREA" 

3  7  22  sav  "LOCATION" 

3  7,35  say  "MEAN’S" 

3  7.45  sav  "HIDKT" 

3  ”,55  say  "VELOCITY" 

3  3,13  say  replicate ("  =  "  ,  4) 

1  3,22  say  replicate ("=" ,  3) 

3  3,35  say  replicate ("  =  "  ,  5) 


3,45  say  replicate ^ " ,  5 
3,5  5  say  replicate ,  3 


ciose  al_ 

^ -  Calls  CHOOSING  to  select  the  crossing  sites 

do  CHOOSING 

3  22.14  say  "Press  anv  key  to  continue  or  Press  "a"  to  EXIT  :  " 

3  22,54  say  ""  get  OPTION 
read 

store  upper (OPTION)  to  OPTION 
re  turn 

-==::==============  END  OF  SELSITE . PRG  ================- 


n-k7'-k7r-k7>-k-*‘Kmx-k-k-kvKn-x-k-k7*-k*K-k-k-k'ryr-x-k-ir-r7**: 

I  K  AREA  .  PRG  _  . 


Module  name 

:  IMARE 

Purpose 

:  This 

Called  by 

river 
:  SELF* 

Variables 

Local 

:  AREA, 

- -  Define  the  local  variables 

- - AREA  :  River  crossing  area,  A  cr  3 

. . LOCI,  L0C2  :  Coordinates  cr  the  crossing  area 

store  spaced)  to  AREA 
store  sbace ; 2  '  to  LOCI,  LCC2 
store  'LEFT  to  LOCI 
store  NIDLLE  to  LOC2 
store  A'  to  AREA 

*  . . . TEMP  contains  all  crossing  sites  m  the  river 

*  . -  TEMP_A  contains  all  crossing  sites  m  area 

*  . . TEM?_B  contains  all  crossing  sites  m  area 

i^e  TEN? 

index  on  LOG  to  TEMP 


:?  index  TEMP 

a 

re  upper ( substr ( LOCI , 1 , 2 ' 
v a,  1 '  sub  s  t  r  ;  LOCI  ,3,3!) 
val  substr ( LCC2 ,3,3: 

'  *  3  '  '  'u\£,  c  £  1  £  -  .  ) 

val ' substr (LC 22 . 5  ,  3  : ) 


-V S  A  A  u  >  ■  •  ».■  r  .  '  >  •  >  A  k 


c  in 


jO  CO 


he  top  of  data  file  TEMP 


e  . not .  eof , ) 

e  coper { substr (LOC, 1 , 2) )  tc  ? 
va  1\ subset  i, ICC  ,2,30 
val v substr ^  LGC ,6,2}) 

;  =  p 

do  case 

case  A X  <  AY 


c op v  tc  TEMPI  next 

1 

for 

(  T<  =  U 

.  and. 

U<=V 

) 

* 

V 

V-;=U 

.  and. 

U< 

case  AN  =  AY 

cccv  to  TEMPI  next 

1 

for 

( (T<=U 

.  and . 

U<=V 

) 

* 

i 

vc-u 

.  and. 

t  T  - 

O  ^ 

> 

,G<  =  R 

.  a  r.  G  . 

R’ 

( 

S<=R 

£>  »*.  ^ 

case  AN  >  AY 

copy  to  TEMPI  next 

1 

for 

(  Q<=R 

.  and . 

?.<=s 

) 

i 

S<=R 

.  and . 

R< 

endcase 
if  AREA  =  "A" 

select  TEMP_A 

else 

select  7EM?_B 
g  r.  d  2.  f 

Hcc^nci  from  TEMPI 


Exit 


RIVE? 


lie 


RIGHT 


END  OF  IMARE . ?RG 


CHOOSING.  PR 


CHOOSING . ?RG 

Ihis  is  a  sub-module  cf  SELSITE  to  select  the 
- . -  -rossir.a  sites  m  area  A  and  3. 


iSRGE ,  MRAFT,  KLINE 

yr-T-w-  rK-k-*;-*-*-*  ^  ’*’**'*  —  ’* 


-  Define  the  local 

River  crossing  area  A  ar.d  5 
Number  cf  bridge  sites 
.Number  of  raft  sites 
Line  control  variable 


variaoi1 


con 


'.cams  the  selected  crossing  sites 


?  MLINE.44  sav  LTR 
a  ML I ME , 56  sav  M4T6 
ML  I ME  =  kline* +  : 

3  AFB  =  SAFE  +  AFB 
5LTR_  =  SLTR  +  LTR 
5M4T6  =  SM4T5  +  ML  To 


E  =  ML I ME  +  1 

IME .  17  sav  "SUBTOTAL" 

INE  ,32  say  str 'S5AFE  .  3 , 1  > 

- . .  z. ,  4  ~t  say  s  t  r  ’  S  —  X  r.  o  - ) 

IMF.  55  sav  str  ( SM4t6 ,3.1) 

say  "HOLDING" 

:::E-ri,32  sav  str;MAFE,3.1) 
IME-h1,44  say  s  t  r  ( HLTR ,3,1) 
::;E*1,55  say  str ( MM4T5 ,3,1) 
=  MAF3  t  SAF3 

=  MLTR  +  SLTR 

•:  =  MN4T6  +  SU4T6 


“  "  7 

S  a  y 

.  ->  i.  n  l. 

z  .  z  2. 

s  ay 

str \TAFE , 

3.1) 

3  !  44 

sav 

str i TLTR , 

3,1) 

3 ,  56 

say 

str ' TM4T3 

,3,1) 

4,17 

say 

"REQUIRED 

1 1 

4,32 

say 

s  tr  v  RAPE , 

3,1.) 

4,44 

s  a  y 

str ( PLTR , 

3 , 1 ; 

4 , 5o 

say 

str; RX4T 3 

2  1  ) 

5,1- 

s  a  v 

renlioate 

44 

7A73 

pv 

f.t  D 

71  _  r. 

-  r 

_  «  r. 

7M476 

T  £» 

11476 

5  =  "b 

:3AFB  =  abs (SAFE) 


. .  h  >  -  U 


5_5LTR  -  abs  SLTR) 

U4T6  3 
5M4T5  =  C.O 

3SM4T6  =  abs ( SM4T6 ) 

IME-7,1?  say  "LACK" 

INE-7,32  say  str  ( S3AFB  ,3,1) 

INE-7, 44  sav  s tr ( SSLTR  ,3,1) 

INZ-7,55  say  stn'SSM4T6 ,3,  i ) 

l"*  say  str(MUMIT)  +  "DOES  NOT  EXIST  !!" 

>r  to  R+ 

••=  3  .and.  SLTR  :■=  0  .and.  SM4T6  >=  0 

.13  say  "Operation  is  possible,  if  you  get  support 

,19  say  "Equipments  are  net  enough  for  operation.' 

say  Press  any  key  to  continue  or  Press  ’X"  to  EX1 
:r  to  W 

say  1  get  OPTION 
;aer(C?Ti:M)  to  OPTION 


Module 


GENERATE  .  ?  R  G  **** 


r-»T-r.T-v»^^TTTX^jriT^?r^^x5xr^’cxx7i:'txxAx^Krc^r7XA^xKXxAx?:KxxAxKxr:x 


L  e  d  b  y 
.ables 


:  GENERATE . PRG  * 

:  This  is  a  GENERATE  module  to  estimate  the  fini-  * 

siting  time  of  river  crossing  operation.  * 

':  TRIPRAFT ,  CALCATM  * 


:  KV_HRAFT ,  H7_ERGE ,  LV_LTR ,  LV_HRAFT ,  LV_3RGE , 
KV_TOTAL ,  LV_TOTAL ,  AT_HRAFT ,  AT_ERGE  .  AT_1.TR,  * 
HV_HOUR.  LV_HCUR ,  HOUR,  NOHRAFT ,  KOERGE,  NOLTR,  * 

T~irnr  tt  t  r  r-  * »  t  -- 


TRIPS,  H_VEH,  L_VEH 

rxxxxxxx^xxxxxxxxxxxxxxxx-^'"xxxxxx^xx,^^rxxxxxxxxxxxx:'rxxxAx','''xxx‘’ 


Define  the  local  variables 


HRAFT 

Number  of 

heavy 

vehicles 

crossed 

by  HV . raf 

BRGE 

Number  of 

heavy 

vehicles 

crossed 

bv  bridce 

LTR 

Number  of 

light 

vehicles 

crossed 

by  LTRcce 

HRAFT 

Number  of 

light 

vehicles 

crossed 

bv  HV.raf 

BRGE 

Number  of 

light 

vehicles 

crossed 

bv  bridge 

TOTAL 

Total  numoer  cf 

crossed 

heavy  vehicles 

Total  number  of  crossed  iio.ht  vehicles 

Heavy  raft  assembly  time 

Bridge  assembly  time 

LTR  assembly  time 

Heavy  vehicle  crossing  time 

light  vehicle  crossing  time 

Heavy  cr  light  vehicle  crossing  time 

Number  of  heavy  rafts 

Number  of  bridges 

: lumber  of  LTR 

Number  of  trips  per  hour 

Total  number  of  heavv  vehicles 


Total  number  cf  light  vemcles 


AFT,  H7_3RGE ,  L7_LTR,  L7JHRAFT ,  L7 
TITA1 ,  L7  TOTAL 

_HRAFT ,  AT_BRGE ,  ATJ.TR,  HV_HOUR ,  L' 
FT,  'MERGE ,  NOLTR,  TRIPS,  H  VEH .  L_ 

-  Calls  TRIPRAFT  to  calculate  the 

-  and  number  of  rafts. 

TRIPS,  NOFRAFT ,  NOLTR 

-  Calls  CALCATM  to  calculate  the 

AT_HRAFT ,  AT_ERGE ,  AT_LTR ,  N03RGE 
•=  AT_HRAFT  .or.  H7_HOUR  <  AT_3RGE 
AT_HRAFT  .and.  NOHRAFT  <>  0 
=  HV_HRAFT  +  (  iRIPS  r  NOHRAFT  ) 


3RC-E  ,  ; 


7_H0UR 

VEH 


nr. 

trips  per  hour 


he  assembxy  time 


HV_T  OTAL  +  H7_HRAFT 
H7  HOUR  +  1 


Calculate  crossed  heavv  vehicle: 


-  Calculate  crossed  light  vehicles  bv 

'-TOTAL  =  L7_ TOTAL  +  LV_LTR 
=  LV-HO'JR  +  1 

lie  LV_JCTAL  <  L_ VEH 

-  Calculate  crossed  light  vehicles  bv  LTR,  BRGE  and  HV 

■_LTR  =  LV— LTR  +  {  TRIPS  *  MOLT?  ) 

:  H7-H0UR  ■=  LVJHOUR 

L'.'-HRA.FT  =  17— KRAFT  +  :  TRIPS  *  NOHRAFT  *  2  ) 

LV-SRGZ  =  LV—HRGE  +  (  200  *  M03RGE  ) 

'.dir 

’—-OTA*.  —  -;_.G.AL  e-  LV— LTR  +  LV_ HRAFT  +  LV  ERGE 
•-HOUR  =  LV— HOUR  -  1 

_H0’JR  >  LV— HOUR 
NCR  =  HV— HOUR 

FOR  =  LV-HOUR 

20  to  S,54 
olor  to  W 

24  say  ‘'EXPECTED  FINISHING  TIME" 
olor  to  W 

-4 . say  "HEAVY  VEHICLE  :  H  +  " 

IS,  say  1 1  r  irr.  ( s  t  r  ( HV_ HOUR  )) 

24, say  "LIGHT  VEHICLE  :  H  +  " 

4i,sav  1 1  r  i.T;  \  s  t  r  ( LV_HC  TR  ) } 

~  "  Q  V-  T-  0 

24  say  "FINISHING  TIME  :  H  +  " 

4  5  say  itrim:_srr  (HOUR;  ) 

I,  say  "End  of  running.  Press  any  key  to  back  input  mode  : 

-ft 


ucoer (OPTIONS  to  OPTION 


END  OF  GENERATE. PRC- 


■xTt'k-k-kTKXTr-kk-rc-x-k-k-k-k-k+tTCTt-.r-r-r-kx?' 

I  R  I  P  R  A  ?  T  .  ?  R  G 
narr.e  :  TRIPRAFT  .  PAG 

:  ihis  is  a  sub-module  of  GENERATE  to  calculate  th 
available  trips  cf  rafts  ar.d  number  of  raft, 
by  :  GENERATE 
es 

cal  :  RAFTS ,  TRIP, 
s  TRIPS,  NOHRAFT,  MOLTR 

-  Define  the  local  vanabl 

-  RAFTS  :  Number  of  rafts 

- T=I?  .  :• -a liable  number  of  trips  per  he 

o  RAFTS ,  TRIP 


TRIP  =  2 

er.dcase 

if  REAMS  =  llH_RAFT" 

MOHR AFT  =  MCHRAFT  +  RAFTS 
endii 

if  MEANS  =  ,;L_RAFT" 

.  ••TIER  =  N'CLTR  *  RAFTS 
er.air 

*f  -  “LJRAFT"  .or.  H_RAFT 

.  Trv,?S  =  TRIPS  +  TRIP 
^ nc  *  ^ 

TRIPS  —  TRT~  /  (  1  Q!|7T  J.  D  D1CT  \ 


/  (  A _RAFT  +  BJRAFT  ) 


encdo 
close  all 
return 


=====  END  OF  TRIPRAFT.PRG 


^i^**^*”*****1*********^**************************^**^**^*^ 

_ . C  A  L  C  A.T  M  .PR  G  **** 

*  -odu.e  name  :  CALCATM.PRG  '''  '  * 

r  *u;‘?C5e  :  A?  a  sub-module  of  GENERATE  to  calculate  the* 

*  tf(s.uo'?r*.  tl,T-  0<3  briage  and  rafts. 

C»  :  j£r»£r.**i-. a  » 

'  Variables  * 

*  ,  Local  :  SETS,  SSET,  TIME  * 

parameters  A_HRAFT ,  AT_3RGE,  AT_LTR ,  MCERGE 
set  talk  off 

. Z":"“-T - Define  the  local  variables 

b~xb  '■  Sets  or  equioments 

, . ;=t:S  :  Sets  cf  ecuibments 

-^ZZI'n"ZZ"c--c""cc--'‘i— r, ,1  finishing  ‘time 


SETS 

SSETS 


store  0  to  SETS,  SSET,  TIME 


select  1 
use  CP.OSSEJP 
co  w r. i _ e  .net.  eo  f  ( ) 
if  MEANS  =  ~ 'LTR|; 

,  AT_LIR  =  A.T  I  ME 
e  n  d  i  f 

if  MEANS  =  '  M4TS11 

ATJjRAFT  =  ATIME  /  NORAFT 


Define  the  working  area 


sexect  SELECTED 
cc  while  .not.  eof  ( ) 
ir  MEANS  =  1 SRGE 1 

SSET  =  WITIH  /  43.2 
ScTS  =  SETS  +  SSET 
N03RGE  =  I.'CBRGE  r  1 
encif 
skip 
enddo 

,=T_ERGE  =  TIME  *  SETS/  NQSRC-E 
lect  CROSSED? 


LND  Or  CALCATM 
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